Functionality-wise, it seems very similar to just “git cloning” another copy of the repo in a different directory (you can even use the “main” local repo as its source, and “pull” from that), which at least to me seems more intuitive to reason about and doesn’t require me to learn any new commands or worry about any limitations like the issues with submodules or not being able to have the same branch checked out twice (clones don’t mind).
It’s a nice idea, and I’m going to try to remember them as an option for future scenarios where they might be useful, but I think the reason they never caught on generally is just that they’re not bringing anything to the table that can’t already be easily accomplished by other means.
Yeah, I didn’t see the use for them until I got further into it over just cloning. Your worktree “folders” share the same git history and stuff. So you can stash in one and apply in the other. If you do a fetch in one, it fetches for all of them.
Whether it’s worth it for others to learn these just for those things is hard to say. I picked it up simply because I was bored and wanted to pick up a new “thing”.
Yeah, I think their saving grace is that they really aren’t that hard to use. I don’t use them often enough to remember the commands by heart, but it doesn’t take me long to figure it out anew each time. Typically not as long as cloning the repo anew, at least.
git worktree is just so much easier to work with if you want to work on multiple versions or branches of some code.
It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.
Trying to emulate this with multiple clones feels like trying to do OOP in C – sure one can do it, but it’s pointless hassle compared to a fleshed-out solution that works right out of the box.
Not to mention it’s so much faster and more efficient than git clone.
Worktrees take less space, and the fetch/pull only has to be done once. It’s a nice feature but restricted to workflows where you work on a lot of features at the same time.
Functionality-wise, it seems very similar to just “git cloning” another copy of the repo in a different directory (you can even use the “main” local repo as its source, and “pull” from that), which at least to me seems more intuitive to reason about and doesn’t require me to learn any new commands or worry about any limitations like the issues with submodules or not being able to have the same branch checked out twice (clones don’t mind).
It’s a nice idea, and I’m going to try to remember them as an option for future scenarios where they might be useful, but I think the reason they never caught on generally is just that they’re not bringing anything to the table that can’t already be easily accomplished by other means.
Yeah, I didn’t see the use for them until I got further into it over just cloning. Your worktree “folders” share the same git history and stuff. So you can stash in one and apply in the other. If you do a fetch in one, it fetches for all of them.
Whether it’s worth it for others to learn these just for those things is hard to say. I picked it up simply because I was bored and wanted to pick up a new “thing”.
Yeah, I think their saving grace is that they really aren’t that hard to use. I don’t use them often enough to remember the commands by heart, but it doesn’t take me long to figure it out anew each time. Typically not as long as cloning the repo anew, at least.
git worktreeis just so much easier to work with if you want to work on multiple versions or branches of some code.It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.
Trying to emulate this with multiple clones feels like trying to do OOP in C – sure one can do it, but it’s pointless hassle compared to a fleshed-out solution that works right out of the box.
Not to mention it’s so much faster and more efficient than
git clone.Worktrees take less space, and the fetch/pull only has to be done once. It’s a nice feature but restricted to workflows where you work on a lot of features at the same time.