Git's Best And Most Unknown Feature

HOW HAVE I NOT HEARD OF GIT WORK TREES??? WHAT THE EFF. They are so incredible. You have to check them out!!! In this video I go over them briefly, assuming you are smart enough to understand them, and also show you my workflow with vim! Its fantastic!
Links
Linode: linode.com/prime
Discord: / discord
Twitch: / theprimeagen
Insta: / theprimeagen
Twitter: / theprimeagen
VimRC & i3: github.com/ThePrimeagen/.dotf...
Keyboard (15% off, I don't earn commission): bit.ly/primeagen-adv2
Keyboard: ohkeycaps.com/products/thepri... (PRIMEDACTYL $25 off)
#vim #linux #git

[@f23anone82]

Honestly, when I watch Linux related videos (git, vim, window managers, core utils, configurations, Emacs) I feel like prehistoric cave-man who somehow got on the alien's spaceship. Sometimes I can even understand how things work

[@ThePrimeagen]

Why don't you just hop on for a ride? Perhaps stay a while

[@manoel.vilela.neoway]

It's normal when we are indeed in a prehistoric life style using software that should be in a museum, like Windows

[@Titere05]

@@manoel.vilela.neoway Powershell is indeed like someone took unix console and thought, "how can I offer this same functionality but in a more verbose, obtuse way?"

[@fl3sh475]

You should create series how to use git ;)

[@ThePrimeagen]

Hah! I have thought about it, but as you can even see from this comment thread, people always tell you that you are wrong and X is the best way to do things. I'll share things that are exciting, but I am not a fan of being a teacher.

[@fl3sh475]

@@ThePrimeagen How cares what people say, do what you are excited about. I would love to see your git workflow from the new branch to push.

[@Kevin-ld1pp]

I would love to see that! It depends on personal preference and workflows, there is no right or wrong. (Except for the emacs vs. vim debate of course)

[@SystemSigma_]

I would suggest a video on terminal customization (zsh)

[@MaxCoplan]

@@ThePrimeagen `git add .; git commit -m "stuff"; git push` what more do you need to know?

[@plankguitars]

I have actually been using this feature for years as a deployment mechanism to deploy different states of the code to different folders that are mapped to different sites, to test different behaviours side by side in test/integration environments 😅

[@JP-hr3xq]

Cool use case ngl

[@BjarkeBruun]

Cool feature - thanks for sharing I would mention that you actually don't need the "git clone --bare " you can just name your "master" clone accordingly eg git clone ${repo} ${repo}-master cd ${repo}-master And then for each branch you want to work on in a worktree git worktree add ../${repo}-${branchname} #

[@fabiano-co]

I'd the same doubt when watching the video, then I started to play with the --bare flag, and yes, you don't need it, but it's handy. $ git checkout -b foo fatal: this operation must be run in a work tree --bare prevents you to screw-up your repo and forces you to use work trees, cool!

[@BizGuzlur]

I was about to write exactly the same thing. I've used worktrees without bare repo, and most worktree examples I've seen don't use a bare repo. Also navigating around and manipulating directories inside a bare repo (equivalent to the .git directory on a normal repo) is tempting fate - one day you'll accidentally delete/change one of the repo directories and break your repo.

[@mfyoutube5003]

Hey! I recently got into all these sweet tools and I started git recently, but I only use it to have a trace of all the changes I do on important projects. I love the way you talk and present things! I'd love to see you present a way to work with git and explaining its tools. About what you said to another comment: that people will say there is a better way ect... you can say that : this is my way of doings things, I don't say it's the best, I just present mine so people that are new can see the possibilities. You're not being a teacher, you're still presenting stuff :D Thank you for your content !!!! Cheers from France

[@ThePrimeagen]

Thanks bud :) appreciate the kind words

[@TimPushman]

Cool to see that even the Primeagen gets files like ":w" sometimes :)

[@ThePrimeagen]

If they happen, I keep them. For posterity sake!

[@f23anone82]

You can map :w to w and forget about this issue

[@TheJobCompany]

@@f23anone82 that just doesn't feel the same as :w

[@mattpeterson7074]

Pretty cool feature. I don't think I'll integrate into my workflow because git stash works for 99% of my use cases (I'm not often being asked to change directions in the same project), but good to have the knowledge about worktrees if I'm ever asked to change it up and do more work on a singular project.

[@spottedmahn]

It’s been 2 years… still the best thing since sliced bread?! In all seriousness, a two year later retrospective would be great!

[@fastandfidler]

I just downloaded your worktree plugin, my life is forever changed now! Thank you so much for making my life easier!

[@hosmanadam]

Interesting, I just never had this problem you pitch at the start. I rarely even stash, stashes are too easy to forget about. If I have to check out a different branch while having uncommitted changes, I just do a WIP commit with a meaningful name that will be sitting right there when I get back. It's to be amended later. On the remote, there is a push rule that rejects any commits that start with WIP. So these WIP commits are self-descriptive, you don't forget them and you can't push them by accident. As for the worktree, I feel like having a bunch of different folders with uncommitted and unnamed changes hanging around would create more problems than it would solve.

[@thiagoruiz]

Totally agree with you, @adam. The only difference is that in my work I push the WIP branch, I like to have the backup somewhere

[@Titere05]

Hey, to each their own. I'm going to try out the worktree for a while and see how it feels. In my job I'm constantly having to put work on hold to deal with bug reports, little last minute changes that the head wants to put in, etc., so this might be a good thing. TBH though, working with stashes felt OK already, but at least now I won't have to type branch names everytime I have to switch

[@TwoLeggedTriceratops]

I was in the middle of a big restructure while trying different tools/libs out, leaving a trail of config files and whatnot scattered about not in their final resting spot (unversioned). I think in such cases this feature shines when you need to pivot quickly and don't want the overhead of having to think which files you want to track, commit even with WIP in the message, etc. Also, I never felt right having untracked files lingering around when switching branches (probably won't affect me 99% of the time, but just how I feel). Previously in this type of situation I would clone the entire repo down again and work from there, but this might save me that hassle and space.

[@Westar.]

You blew my mind in the first minute. This is game changing. Thanks prime!

[@ThePrimeagen]

Most excellent. That's how I felt

[@kevalan1042]

@@ThePrimeagen why is it game changing? I think it's neat but I don't see the amazingness of it yet

[@josejoaquinalonso601]

As usual, your videos are awesome, keep it up Primeagen!

[@ThePrimeagen]

Yayayyayayayayaya

[@BryanJenks]

BRUH. This is going to make the work at my day job SOOOOOOO much easier. Legit AF

[@ThePrimeagen]

Yes. It. Is.

[@rishushrivastav4591]

Ohh my I just woke up and this is what I watched I have been searching for a proper way to do this forever Man you are a life saviour @ThePrimeagen

[@ThePrimeagen]

yayayayayaya! My plugin is 90% there too. It doesn't handle non bare repos as well :)

[@maclarel]

How the hell did I not know about this? Awesome walkthrough. Thanks!

[@ThePrimeagen]

This was literally me 2 weeks ago

[@Jubijub]

Oh boy...every year I have 4-5 of those "huh, I need to adopt this right now" moment. This is definitely one of those, thanks for explaining Git worktree !

[@AndreioxMacedo]

Damn... you know how to blow my mind with git things. Last time was with fugitive and now with this. Amazing! Thank you.

[@ThePrimeagen]

Yaya! Huge fan of fugitive, now this :)

[@offwhitemke]

What I do when I need a separate workspace is to simply create another folder and clone from the other local folder which was already cloned. I can then push and pull from the origin which is simply the other folder. I can name the remote whatever I want and do this with multiple folders to isolate my work and make it easy to move commits between them.

[@ThePrimeagen]

Interesting.

[@offwhitemke]

@@ThePrimeagen It’s been useful to do this for probably the same advantages of a worktree. But I like how I can set as many remotes as I want. And with my company workflow we have multiple workspaces with the same packages and I have those for working on different issues. Some are quick changes and others are longer term projects. Cherry picking commits, like debugging code, a bug fix or optimization, has been easy. I recommend it. No need to even push a branch beyond my computer.

[@AnthonyBullard]

This falls apart for projects with a large number of commits. Your machine is just GBs of .git folders(if you have any GBs left after installing node_modules if you are stuck using npm)

[@adheusrangel]

That's truly awesome! We'll definitely give it a try.

[@ThePrimeagen]

I think they are the bestest!

[@Alpha_Dev]

Awesome, I didn't know that I needed this. Thanks

[@ThePrimeagen]

I am only a few weeks into them, and they are by far the best thing I have used in a while!

[@alex-lp6pw]

Aaahh, I need this in my life. I can just checkout code to review it without disrupting what I’m working on. Thanks!

[@ThePrimeagen]

This is fax

[@iainearl6669]

This looks amazing! How does it handle large projects? I work with a pretty sizeable monorepo (takes gopls 2-3 minutes to start and uses ~11GB of memory =[). Is each worktree folder the size of the entire project?

[@ThePrimeagen]

So i have a 7 million line of code cpp repo that I have like 50 branches of. Its still less disk memory than 3 checked out repos. I don't know about LSP memory requirements. I have no idea how much memory my LSPs take. I just want them to be awesome :)

[@iainearl6669]

@@ThePrimeagen Awesome! Definitely trying it out. Everyone at work tells me to use intellij instead. I installed it, and it took 2 minutes to open before I could even edit any files. Straight back to neovim

[@riccardoodone]

Instant subbed to your channel. This video is so informative and fun that makes me want to go back to record more KZbin videos. You rock! (Going back to re-watch it for the n-th time now.)

[@ThePrimeagen]

Oh snap! Tyty

[@steabert]

The bare repo stuff is new to me, makes a lot of sense to use with worktrees. Thanks!

[@ThePrimeagen]

Yeah! You don't have to have a bare repo to use get work trees, but to me it just feels funny.

[@glennoberlander5005]

Curious, why does it make sense? I am newish to bare repo's and worktrees. My understanding is that a bare repo is just the repository (no workspace), so, is using a bare repo and creating worktrees for so you can clone the repo as a bare repo, then when you add a new worktree, it clones the workspace? (pulling from github or wherever it might be). It seems dealing with the refs is a pain if you use this approach, but seems there are ways to make it automatic

[@Skylla54]

Did he touched his mouse o.O This is not the content for what I am subscribed for! :' D Keep going man, love it

[@andrewrivera7468]

You can use fixup during a rebase to drop commit messages for work-in-progress commits. Works great.

[@yt-1337]

you still need to change the original commit message, you probably don't want to fixup the wip commit into another unrelated one

[@benjaminschultz6501]

I've been wanting a slick way to view two branches at the same time and edit them simultaneously. BOOM! Problem solved. Thanks, Prime!

[@garfieldnate]

I would have some issue with JS projects needing to have a humongous node_modules folder under each worktree directory, but I can see this being super useful for other types of projects where I'm jumping back and forth between branches constantly to test changes or find differences. It can be really useful to have two IDE windows open with a different branch in each, and I used to just clone to another directory. No more!

[@nfrid]

pnpm symlinks dependencies, check it out

[@yt-1337]

wait do node modules get committed???

[@MilesRayne]

@@yt-1337 Absolutely not. He's talking about having huge node_modules folders locally in his project folder, now having X branches with X node_modules folders instead of one.

[@ghislainthau]

​@@nfridor for yarn users nmMode: "hardlinks-global"

[@ghislainthau]

@@peterdenham If you work at a company with tens or hundreds of repos, all setup in a standardized way using yarn workspaces, and publishing and CI depend on yarn workspaces specifics, you can't just use pnpm. It might be almost a drop-in replacement for small projects, but once you reach a certain scale, switching things like package manager, monorepo management tools, CI system, etc. is a huge task that wastes a lot of time and bring next to nothing as a benefit.

[@nro337]

This was so helpful. Thanks!

[@ThePrimeagen]

Awesome to hear :)

[@cdrini]

This is super interesting, thank you for sharing! I'm trying to think of what the best way to integrate this for me would be. My current flow is to have little "buttcap" commits when I have to switch contexts; something like `git add -u && git commit -m "TMP"`. Then when I come back, I `git reset --soft HEAD^` and continue where I left off. It seems like worktrees might be useful to have like different "lanes"? So I could have a main worktree for my primary development, and a maintainer worktree for reviewing PRs/etc. That would be good because node_modules/etc would also be independent. Not sure. Regardless, glad I learned about this! Time to read some docs :) Edit: Oooh! Also for longer lived branches, like major version bumps.

[@ThePrimeagen]

effectively, yes. Gitworktrees are like lanes. Each checkout refers to a commit. You just do your work on that commit. That way you don't have to do that dance with the jumping around to stash / unstash / commit / uncommit, etc etc. yes. node_modules are nice because they are independent and you don't have to continually update as you swap all around. with the vim plugin I made you can add _hooks_ to your creation / switch process and will allow you to do the updating / npm'ing in the background.

[@MrKyuubiJesus]

I personally just commit once and the have an alias "am" for "git commit --amend --no-edit" for keeping it a single commit. In case I accidentally do it to the master HEAD commit I do "git reset --soft origin/master" and I'm good to commit

[@laerciooliveira6326]

I didn't know this feature. Thanks for sharing.

[@batboy49]

Holy cow I am excited....you know how I was doing this? I was checking out multiple copies of the repo...what a PITA.....I AM FRICKEN STOKED!

[@ThePrimeagen]

i love this

[@kirimi782]

I am just wondering, does rebasing changes in one worktree work the same as with other branches?

[@wingwhiper]

Man I needed this sooner in my life

[@parametr]

Nice one. Sometimes changing branches will just screw up autogenerated stuff you shouldn't commit nor stash (I'm looking at you Apple and MS; wtf with XCode and VS "Solutions"?). I wouldn't use it instead of branches, but when branches won't do... this one goes right into the toolset to advise everybody about.

[@jesse9999999]

wow this is nice for workflows where you are building a lot of features simultaneously at the start of the project. new worktrees for each little feature you go to would make a way cleaner commit history.

[@ivanjermakov]

Use branches.

[@lelandkwong]

Omg... this feature is mind blowing. Yet another amazing thing about git that I never even knew existed.

[@ThePrimeagen]

It's crazy that this can still happen

[@therealsunnyk]

I like worktrees, but one of the downsides is support. Often when some tool has git support, it doesn't tend to have worktree support :(.

[@yt-1337]

don't use git integration with these tools then, git on cli is very comfortable and atleast i know what i'm doing vs whatever the software thinks it wants to do for me

[@weizheheng3900]

I am imagining whether git worktree can work with git flow or it totally replaces it? But yeah, it looks cool, and I will definitely check them out! Thanks for sharing this

[@ThePrimeagen]

It seems to work well with any tool thus far I've used.

[@taher1517]

What would be the solution for when you have for example an environment file or a local_settings.py (django python) that you want shared across all worktrees? would you need to copy it whenever you add a new worktree?

[@aciidjj3594]

This is insane i was dreaming about such a feature for months

[@NostraDavid2]

We squash each PR, so commits with "wip" in it are pretty regular, because they get squashed anyway. The name of the commit is whatever you pass into the PR that we create in BitBucket.

[@KeithBalante]

Mind is blown thank you so much ☺️

[@romainheller8263]

Great, I didn't know about git worktree until seen the Prime fight againt the Foo !

[@ThePrimeagen]

The foo fights all. We must defeat.

[@plasticcreations7836]

This is so good they should advertise it on every git command ;)

[@DJazium]

OMG I did not know this existed. this is a huge game changer for me!!

[@bengamedev1872]

I find git stash / commit and switch to be my preferred approach. Reviewing a ton of branches and going through a variety of commits by several people would be insane to have separate worktrees for each

[@cheebadigga4092]

Thank you so much!! Only realizing this now lol

[@jandrews377]

If I need to work out of a single webroot, am I stuck stashing when switching branches, or does worktrees allow for changes on branches to remain unstaged?

[@user-xd5gd4pc9h]

I come to see this again. I want to know how to compare (one file) between different branches? Thx Primeagen!

[@sudodoas]

BTW, which terminal emulator do you use and have you ever tried DWM? -fellow dvorak and linux user

[@ThePrimeagen]

I just use gnome terminal with the zsh shell

[@con-f-use]

Hi, is there a good option to convert a regularly cloned repo to the worktree layout. I'd like to do that for a bunch of large-ish repos and would hate to download them again.

[@nicolaisattler1990]

Thanks for this great tip!

[@ThePrimeagen]

You are welcome!

[@MortonFox]

In the situation where I have to make a hotfix to the main branch while working in a feature branch, I just clone the repo again into another folder. However, worktree sounds like an interesting alternative. I'll have to try it to see if it is better or faster.

[@ThePrimeagen]

You can even use it on a non bare repo. So theoretically you could actually put the work tree where you would clone the second copy.

[@constroyanonymous7830]

Hey prime I am a huge fan of your content and started using VIM by watching your videos. I am having 1 difficulty while using vim which is movement in insert mode. Since we should not move using arrows in vim the movement in insert mode makes it more difficult like go to the normal mode first go over the character you want to change by going in insert mode again. So is there any efficient way to do this ?

[@ThePrimeagen]

C-o in insert mode will allow for a single command to be executed! Could be for you

[@constroyanonymous7830]

@@ThePrimeagen Thanks i will try it out

[@kirimi782]

You had me at "Tree shitter to the rescue". Super great vid. I like.

[@about47t-rexes12]

What I actually thought was even cooler was your submodule update script? What did you make that in again? I would like to try it myself

[@FlaviusAspra]

Prime, thank you. You gave me the idea, since I'm a CTO, to force all coders to use worktree! Now my suggestion: you should squeeze that in, squeeze the work flow! Let me explain. With worktree you manage the work at a higher level, top-down. Also teach the noobs about git add -pv, gotta squeeze it from below also! Today I've had my first success. After preaching about hunked staging for weeks, the junior of the team finally asked me "what was that command again?".

[@ThePrimeagen]

That is actually pretty fun! I also use fugitive so hunked staging is really straight forward. Just `s` on which you want :)

[@FlaviusAspra]

Yeah, makes you look like you never, but absolutely never, do any boyscouting. You're like all the time the ultimate Merlin, all commits laid out in perfect order, never forgetting anything, endless mental backtracking. Haha, pure mastery. If only they would know the truth...

[@FlaviusAspra]

@@ThePrimeagen make a video on this :-)

[@DavidMoberg]

I'm confused, are you talking about the regular `git add -p`? Thought that was common sense! :o

[@catalinoprea5313]

Hi Primeagen, I've been following you since the beginnings. I followed every single advice from you and I've been training in Dvorak for 2 months now (60 WPM), but now I have a problem. I switched to Programmig Dvorak and navigating through lines got a little bit hard. (4j. 20k). Are you using CAPSLOCK or any other trick? It kinda gets on my nerves to press Shift everytime. Thanks!

[@ThePrimeagen]

totally get that. ** I DONT USE PROGRAMMERS DVORAK ** I use my own custom dvorak, but it does suffer the same problem with shift keys. I effectively measured the output and decided that navigation speed wasn't as important as longer term wrist health, therefore I decided to keep numbers on the shift. I have tried feet switches and they are too slow! I am going to try moving shift to my right thumb here shortly. I'll be making a video on that shortly too. Maybe that will help shed some light.

[@catalinoprea5313]

@@ThePrimeagen Thanks a lot for answering! I'll be waiting

[@thomaswang4875]

I’m learning Colemak recently and am facing the same dilemma around navigation speed vs wrist health. Hope to see the video out soon, thanks!

[@lemonsh]

I use them for my GitHub Pages website to make a clean gh-pages branch built from master using Zola (my SSG) with only one commit on every deploy, neat feature indeed.

[@henriquemarques6196]

I thought that worktree would simply create a new directory for each branch I added to the tree, but it looks like it doesn't really create new files, it actually create hardlinks to the original data so you don't have duplicated files. That seems pretty interesting, my company's node_modules weighs about 400Mb, imagine duplicating that for each branch I have checked out lmao. Now I'm fully motivated to learn worktree, thanks again Prime

[@1vader]

node_modules (hopefully) aren't checked into git though, so they probably would be duplicated. Unless you're using pnpm which already uses symlinks to deduplicate dependencies across projects.

[@RefactoringRyan]

You’re a goddamn saint brother. Thank you for sharing!

[@ionelCristianLupu_]

This is very similar to "Shelve changes" in Intellij IDEA. Nice

[@albertlee9592]

At 3:31, I am like “oh f%#$&ing yeah...” . Thanks for sharing this awesome not so well unknown feature about git!!!

[@ThePrimeagen]

Its shocking how its been around for years, and I have literally never heard about until this year. I feel big dumb :)

[@Deltax64]

Not sure how easy this would be to integrate into my workflow because the repo I’m working on effectively acts like a submodule, so the build system expects the project root to be a certain way. If I’m using worktrees then the project root is messed up and I’d have to point it to my current worktree or something instead via symlinks - not sure if this is even possible

[@ThePrimeagen]

That is interesting. I added hooks to the plugin I use so if you can "update" the toolchain's "root" then you should be _able_ to do it (but I am sure, as life always is, it wont work :))

[@Markor91]

what a funky keyboard you have!

[@gustavstreicher4867]

I wanted something like this bad enough I added another command to my local git that runs a bash script. Yes, you can do that. I call it "git save". It simply piggy backs off "git stash" and creates two stashes with the "save" name prepended on both stash messages for the script to identify them, instead of relying on the stash order. One stash is for staged changes, the other for unstaged changes and uncommitted files. I can then run "git save as NAME", "git save view NAME", "git save drop NAME", and "git save list" to manage "saves". The only benefit workloads would have over this is that they would also have appropriate dependencies and builds in isolated folders ordered by branch, which can be nice. My solution allows you to do this all in the same repo,but with shared deps and builds. So, they both have their pros and cons.

[@krisculin9679]

Great video. My team is migrating the Git this year (from perforce) so I am trying to learn everything I can to make the transition easier. Videos like this are very useful to that edeavor. On a side note - what kind of keyboard is that you're using? It looks really, really cool.

[@sidekick3rida]

kinesis

[@danieloberhoff1]

ok, so in the end this is an optimization where you share the actual data between separate "clones", right? i mean instead i could (and do) just do separate clones in separate states, but this one shares all the git objects between them. but sure a huge enabler for very large repos

[@nomadswe]

Wonder how that works when you have different node packages between the branches cause of updates etc.

[@victoralcorta]

hey Prime, what is the colorscheme you are actually using there?

[@scyth2]

I like the concept of worktrees, but I tried them out for a few months and too many times had to untangle my commit history which would get bolloxed-up occasionally. I chalked it up to my employer's main repo using a lot of submodules: submodules *shouldn't* be a problem, but I came to the conclusion that the two features were fighting one another at some level. Since then I've not used worktrees and life has been idyllic. Well, almost.

[@mwaffi]

`git help worktree` will tell you that "Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject."

[@aerialdude]

Is this really that different from just separately cloning the repo again? I just use multiple clones of the repo when this sort of thing comes up. Btw, I'm not trying to dismiss this, I legitimately am wondering. I might switch to this method if there are other advantages.

[@elieobeid77]

Never heard of this feature, started researching it just now, it seems that using the bare command when cloning isn't necessary, are you sure it's needed? no one is using it also, when a change is made to a worktree, is there a way to automatically pull? well I could create a bash function but :) The thing is, imagine you have 3 worktrees and multiple branches being updated in the workday by different people, it sucks to keep having to pull the master changes on all worktrees one by one

[@ThePrimeagen]

So I have that vim plugin I showed in the video that allows me to do what you are saying. A good fetch --all can help keep your remotes up to date and the pulls are pretty quick then. Yes bare repos are not required, but I have really been enjoying using them.

[@DanielGiljam]

what if you have a branch called hooks? won't that collide with the bare repo folder called hooks when you try to 'git worktree add' it?

[@ludviglarruy1093]

I wish git-worktree was more mainstream. I work in a fairly large company. We have dedicated teams working with delivering development tools. E.g. we have our own IDE (a highly customized Eclipse-based IDE). Lots of different custom build/test tools. I really like the concept/functionality of git-worktree. Problem is that many of our custom tools which interact with git seem to assume developers are using the main worktree. As soon as I try to build/test something in a linked worktree, there is fairly often something somewhere in the toolchain which fails, solely because it was built on the assumption that we’re in the main worktree. I still use linked worktrees for browsing code, but full-fledged development typically requires me to use the main worktree, due to poor tool support. Unfortunately.

[@apefu]

I mean, I feel I had no problem just switching branches but this is just so much easier.

[@tinkumonikalita2576]

Hey prime, that day I was asking about the copy feature for telescope. The one you have in your .vim file is for grepping a string. What I am looking for is like you open a specific folder using telescope, and from here when you press enter on a file name the content of the file is copied and pasted in the current buffer (below or above the current cursor position). Is it possible to do with telescope?

[@ThePrimeagen]

ABSOLUTELY! Check out how I do the anime selector and replace the dconf execution and do something like the following (I am literally making this up, but the commands should be _mostly correct_) ```lua function get_file_contents(path_to_file) -- Path comes from plenary.path local content = vim.fn.systemlist(Path:new(path_to_file):absolute()) -- I forget the exact APIs -- Dangerous part of just this is that it will _REPLACE_ your current buffer -- at the line provide. So you may have to read out the buffer first. vim.api.nvim_buf_set_lines( 0, -- current buffer = 0 -- what line ? You will have to figure this out -- -- to what line? You will want to get the length of the content (#content) false --- it can go off the end of the buffer (buffer will create new lines, content) end ``` Cheers!

[@tinkumonikalita2576]

@@ThePrimeagen thanks so much. This look great. I'll try to implement. Your videos are great and fun at the same time. Thanks

[@tinkumonikalita2576]

With some little modifications I was able to do it. Thanks!!

[@FunkyDeleriousPriest]

Yeah man there is no other way for me to work on a project. I don't think I have ADHD but I definitely can't focus on coding just one change at a time. Need me all those interesting branches available at my finger tips at a moment's notice.

[@donjon61]

I'd love to use this awesome future, but I am not very fond of the fact that I'd need to checkout over 2.7GB each time I want another branch. Because the project I got assigned to has that size since...no idea, a point in time before me. I guess that feature will be helpful for my own projects which aren't nearly as convoluted.

[@josevargas686]

Git clone --depth 1

[@EER0000]

Damn! How did I not know this?! Sounds like a big project to clean up our dev environments, but could be worth it 🤔

[@NostraDavid2]

I presume you have all your repos in ~/dev or ~/projects? Just create a dev2 or projects2 folder and experiment there! You can still keep your old structure around, just in case!

[@Krishtal3]

that's awesome, but how to get branches which was create by others right after I cloned the project with --bare flag?

[@krombopuloslincler4849]

I had to watch it literally 4 times to understand the true power of worktrees.

[@ThePrimeagen]

I hope you have the power now :)

[@robby7292]

This sounds f*** awesome :O

[@megasuperlexa2]

ok, I did it and all of a sudden I cannot now git rebase -i origin/develop like I used to do.. no squashing for me? have to specify local develop, AND pull that beforehand.. and all of a sudden I get 'no upstream' error.. too many steps vs. 'classic' approach.

[@rahulsoibam9537]

How to you git worktree add feature/123. For me it just creates a folder named feature and 123 becomes the branch name.

[@ThePrimeagen]

tldr git-worktree will give you the basics of worktree. You can create the path to be whatever name you want it to be!

[@dave6012]

That’s happened too many times to me. I’ll do my best to learn git worktrees. Maybe with a nice small personal project first 😬

[@rohitpatil3534]

might save my life one day, thanks

[@ThePrimeagen]

Saved my life!

[@williambury275]

I don't use git work trees YET, because of ThePrimeagen !

[@ThePrimeagen]

yayayaya! USE EM

[@TheSnero3]

holy f8ck! how did I not know about this. This is a game changer for me!

[@dae2530]

I prefer `git stash` because I usually have to change many repositories to make something work. ~5 apps, ~10 repos, shared volumes, shared libraries

[@rddavies]

Everybody's workflow is subtly different I'm sure. I can't quite see how this would give me something I don't already have with simple branches. Basically tree, branches, they even sound like they scratch the same itch. What am I missing?

[@yashdiniz]

Whenever you have modified files in a branch, git warns us about uncommitted work. We have to then stash our current work before we switch to another branch. With git worktrees, you can work on multiple branches simultaneously without needing to checkout between them. All you need to do is change directories.

[@rddavies]

@@yashdiniz ah OK I got it. Makes sense. Thanks.

[@jimhrelb2135]

How about .env or niched things like node_modules and the likes that are supposed to be in .gitignore?

[@gustavcoetzee5018]

So excited

[@ThePrimeagen]

much excite from me too!

[@avivhadar5478]

Every time I add a new branch or checkout to an existing branch that exists only in remote I need to reinstall packages?

[@ThePrimeagen]

Yes, you will. But the best part is that you can hook into the checkout process and have it automated so you don't even notice it.

[@avivhadar5478]

@@ThePrimeagen Just when I thought I was out...they pull me back in!

[@Freddyilha]

I'm having a problem with branches that have slash on the name like "refactor/some-name" worktree actually creates a folder called refactor and inside creates the "some-name" branch that is the last commit from develop and not the actual changes from the branch "refactor/some-name". I tried to surround the path with single and double quotes got the same result. Someone had this problem?

[@ThePrimeagen]

The plug-in that I am currently making is just about to have a merge that should fix all of it.

[@Freddyilha]

@@ThePrimeagen I don't use neovim =P, maybe i'll see how you did to do it manually.

[@ThePrimeagen]

If you're doing it manually it usually creates folders deep like that. Which makes sense because a lot of Git Branch naming techniques are folder structure like. That way you can have a bunch of sub branches all sharing the same folder. Also you cannot have a forward slash in a file name.

[@Freddyilha]

@@ThePrimeagen It make sense if i have "refactor/this-name" and "refactor/that-name" they would go to the folder refactor with the branches "this-name" and "that-name", but it does not work don't know if i'm stupid or what but if my branch name have a foward slash i can't use worktree?

[@AqgvP07r-hq3vu]

One disadvantage of git worktree: you should `npm install` again. I've always wanted this kind of feature with git and I was enthusiastic about it at first. I've been using it for a while, but I realized that everytime I create a new worktree I need to npm install again which takes quite burdensome amount of time and space. Recently I've switched back to the casual `git stash` workflow since it works most of the time, but I admit git worktrees might be definitely useful in some corner cases in the future.

[@1vader]

If you use pnpm, it'll just recreate the symlinks which is really fast. But yeah, it's definitely not without issues. Though I've just had a case at work where we're migrating to a new framework version but I had to fix and test some stuff on the old branch, in which case worktrees would have saved me from having to constantly rebuild everything from scratch when switching.

[@AqgvP07r-hq3vu]

​@1vader you're right. Thanks for your feedback! Thats definitely the case in which worktrees would be valuable! I'll try to find more use cases

[@beluv]

So does theprimeagen take the headphones and microphone boom with him wherever he goes?

[@user-if6mq6qr6x]

Any update on git work trees? Are you still using them in your workflows?

[@alfredoportocarrero8663]

i hated git stash, nice to found this vid