Git's Best And Most Unknown Feature

[@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?"

[@stefanalecu9532]

​@@Titere05 better than using Bash at least in every possible way, any form of sh should only be in a museum ;)

[@shambien]

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

[@trejohnson7677]

God damn they're going to think I'm a genius with this next PR.

[@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.

[@VictorYarema]

Thanks for pointing it out. Just one small observation from me. The bare variant has one mental-nano-convenience. It makes setup more uniform. I mean this way all branches are "equal" and have their own dedicated folders.

[@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?

[@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.

[@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.

[@spottedmahn]

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

[@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 :)

[@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

[@fastandfidler]

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

[@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 !

[@BryanJenks]

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

[@ThePrimeagen]

Yes. It. Is.

[@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)

[@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 :)

[@josejoaquinalonso601]

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

[@ThePrimeagen]

Yayayyayayayayaya

[@Armadous]

I dunno, I spent nearly 10 years working with a monolithic TFS repo and this feels like a step back in that direction. Working tree is like why bother cleaning up your desk to start a new task.. when you can just bring in a whole new desk. I know myself and I will end up with a bunch of trees with half baked features that I don't remember what I was trying to bake in the first place.

[@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!

[@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

[@plouf1969]

What's wrong with different copies of the repo?

[@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

[@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

[@kirimi782]

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

[@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.

[@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

[@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

[@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.

[@glennoberlander]

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

[@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

[@adheusrangel]

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

[@ThePrimeagen]

I think they are the bestest!

[@GoddamnAxl]

Wait how is this different than copy pasting your repo folder multiple times? I ran into this situation multiple times and I just copied the repo and checkout whatever I want.

[@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

[@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?

[@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.

[@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.

[@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

[@douglaslassance]

If I understand this right, the advantages of worktrees over setting up multiple clones are getting rid of the download time and sharing the history, thus saving disk space.

[@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!

[@zACIIID]

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

[@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

[@joseville]

1:45 Is "checking out a commit" the same thing as "checking out a branch"?

[@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 :)

[@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!

[@rybakostis]

IDK, at first I thought it would be really useful, but then I looked at huge monorepo over 1GB... nah, WIP commit or stash works just fine

[@AqgvP07r-hq3vu]

Exactly what I thought. Agreed. Unless they come up with a better solution on node_modules and other non-git-tracked-files, stash might be a better option most of the time.

[@plasticcreations7836]

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

[@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 :))

[@tomaszgalkowski8701]

This is good, but with vendored dependencies (node_modules, Go's vendor folder) it becomes a MASSIVE chunky boy very quickly.

[@wolizuka]

It's hard links, not copies

[@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.

[@wingwhiper]

Man I needed this sooner in my life

[@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.

[@jasongomez5344]

2:09 Why rm -rdf? The -d is redundant with -f.

[@艾曦-e4g]

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

[@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

[@AqgvP07r-hq3vu]

I've had a change in mind. I was wrong. Git worktree is indeed useful. Git worktree sits somewhere between 'Stashing' and 'Cloning'. I've realized that developers often clone the same project multiple times to work on different issues simultaneously. They get tired of stashing changes and switching branches constantly. Many developers don't mind running `npm install` multiple times; they prefer this over the hassle of switching branches and managing stashes. In such scenarios, where you're okay with reinstalling dependencies repeatedly, Git worktree can save you some disk space and streamline your workflow.

[@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!

[@patiencebear]

cool, but why? Honest question: Why are you jumping around branches so much?

[@mattmmilli8287]

It’s inevitable once you work on huge codebases with a big team

[@Markor91]

what a funky keyboard you have!

[@laerciooliveira6326]

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

[@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."

[@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.

[@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.

[@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.

[@DJazium]

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

[@ljason6361]

Was use it couple years ago, but it does not work well with large project in monolith modular architecture for some reason. my alternative approach is just to post a base PR to remote and then create branch based on that then merge back to the base branch once it gets reviewed.

[@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

[@nro337]

This was so helpful. Thanks!

[@ThePrimeagen]

Awesome to hear :)

[@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

[@mattymattffs]

Work trees are an awesome feature for certain repos. We have a repo for customer modifications and in that context work trees are awesome. But for our products they kind of get in the way to be honest

[@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?

[@otakosol]

Just tried this; `fatal: 'hooks' already exists` when creating an orphaned worktree, but if the branch already exists you can do something like `git worktree add hooks-dedup hooks`. Not ideal since you still need to remember the path, but telescope can help with that.

[@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.

[@Krishtal3]

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

[@PeterWhite-w2e]

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

[@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.

[@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?

[@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

[@jimhrelb2135]

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

[@urugulu1656]

so essentially like the branches directory with svn... exactly what i need even though i probably wont get a ton of use outta the scripts... :(

[@ThePrimeagen]

I have some pretty snazzy scripts these days. I have really enjoyed it.

[@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.

[@chris.dillon]

6:16 Git submodules are such a foot gun to me because of what you said. "I forgot to update". I wrote a blog post about "moving toward your language tooling" but some people found some bits of it confusing. I need to reword it a bit. I've heard this a lot in C++. I guess the language tooling and cultures are different. Npm and bundler just work on local paths and it's completely recognizable to the community and culture. It's just so default because a dep manager was there really early and the dep manager can work on local paths. I guess you still have to remember to update. Hmm. Nice video, TIL something.

[@ThePrimeagen]

I keep wanting sub modules to be great. They are never great. Ever. But I am going to try again :)

[@michaeletzkorn]

you can configure submodules in git config to always check out whatever is committed when you checkout to someone else's branch or pull changes. It takes away from the "plug, play, customize" utility of submodules but it creates less bullet holes in your feet

[@RefactoringRyan]

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

[@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

[@krombopuloslincler4849]

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

[@ThePrimeagen]

I hope you have the power now :)

[@KeithBalante]

Mind is blown thank you so much ☺️

[@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?

[@teej_dv]

2 SVN users must have watched video :'(

[@ThePrimeagen]

Commented from TortoiseSVN

[@teej_dv]

@@ThePrimeagen Oh, I'm sorry, this resource is locked

[@jesseleite]

Git out Teej. I use Mercurial.

[@shadowking6008]

and then there is me using a Jetbrain's IDE. I am saying this cause i know one person on youtube has a problem with them for no right reason even though they use the font.

[@teej_dv]

@@shadowking6008 I like Jetbrains :) I recommend them to people!

[@crazyst3ve01]

This sounds like SVN again. Have we gone full circle. The biggest win for moving to git was that it updated the folder I was working in, and not requiring folders per branch

[@cheebadigga4092]

Thank you so much!! Only realizing this now lol

[@ionelCristianLupu_]

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

[@tommyholmberg]

I'm sure it's great but this video was a complete cesspool of information. Probably good info but impossible to keep track of.

[@eduardojreis]

2:04 - why `rm -rdf` instead of just `rm -rf`? Is there a situation in which `rm -rf` is not enough?

[@NomadSWE]

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

[@yt-1337]

why not use local branches for this? i mean i prefer to have my tmp changes saved in a tmp commit vs them being not tracked when i switch to another problem for a while

[@kirimi782]

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

[@victoralcorta]

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

[@DavidMoberg]

How do you deal with tracking, fetching and updating of refs with a bare repo?

[@ThePrimeagen]

git fetch --all for updating all remotes. I have a Vim shortcut for this. It can be executed either in the work tree root or in any branch. git pull to pull in the new changes (or git rebase)

[@DavidMoberg]

@@ThePrimeagen Right, thanks. I was missing `fetch = +refs/heads/*:refs/remotes/origin/*` in my .bare/config file. How do you deal with setting upstream? Do you do that manually after `git worktree add` or is there a quicker way?

[@ThePrimeagen]

@@DavidMoberg I have a neovim plugin that does it for me

[@evanjrowley]

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.

[@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.

[@robby7292]

This sounds f*** awesome :O

[@beluv]

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

[@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

[@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.