3 ms·

I've been where OP is. For me it's because, for whatever reason, I don't want to commit my shitty in progress work right now to go work on this interrupt. And i

I've been where OP is. For me it's because, for whatever reason, I don't want to commit my shitty in progress work right now to go work on this interrupt. And if I stash it, I will likely forget I did that, and waste time looking for it again. Worktrees are a different way of managing multiple branches in flight. They're not hard to use, and using them doesn't imply any incompetency with git. They are likely being used to cope with another kind of problem.

nerdponx 3y ago
There are many legitimate use cases for multiple worktrees. Here's one example: I'm working on a trunk-based project, and I am upgrading a core framework like Angular or Django. That's a fairly intrusive change that involves modifying some untracked on-disk artifacts, like node_modules/ and package lockfiles. Switching branches doesn't help me manage those artifacts, and might require a full teardown and rebuild of my dev environment each switch. Even if I maintain a meticulous commit history and never have uncommitted "WIP stuff" that I need to stash, switching from my branch to fix a bug in the main branch could be annoying and intrusive just because of the dev environment. This is a great case for a separate worktree.
- tomjakubowski 3y ago
  Yep, just added similar thoughts myself.
tomjakubowski 3y ago
There's another case where worktrees are great, whether or not you are compensating for other problems. If your project's build takes forever, but incremental builds are relatively fast, worktrees are a good way to preserve build state on the file system between branch switches.
- coldtea 3y ago
  >worktrees are a good way to preserve build state on the file system between branch switches. Why would you ever have build artifacts, incremental or not, as part of your code repo?
  - neandrake 3y ago
    It’s probably not part of their repo, but exists alongside, possibly gitignored. Either way in the same workspace the IDE will have to invalidate a lot of it when you switch, and again so when switching back. Separate clones, or worktrees, mean they don’t get invalidated and your IDE just sees them as a separate project altogether, each with its own cache, regardless of where that cache exists.
kraftman 3y ago
Why not commit what you have and ammend / rebase it later?
mabster 3y ago
I picked up my git workflow from a very commit-centric workplace. Instead of stashing or anything like that we would commit with the text "WIP". Every time we had a stable point, we would make a "WIP" commit and then continue, giving us a good point to revert to if the next steps don't work. If someone interrupts me I would make a WIP commit and then revert it and then make the change they're asking about. Later on we would squash the WIP commits and make real commits out of the changes. Another nice thing about this workflow is that everything goes into the reflog.
- avgcorrection 3y ago
  This is the way. Just commit. You can undo it later or whatever, but at least it’s there. Just one concept instead of (1) commits (2) stash (3) oh these changes, eh, I don’t know what to do with them... let’s think about it after lunch.
scubbo 3y ago
> For me it's because, for whatever reason, I don't want to commit my shitty in progress work right now This is kind-of the million dollar question, though, I think? What would such a reason be? (I ask from a perspective of genuine curiosity, not of implying that you're wrong to have them)
- erik_seaberg 3y ago
  I don’t want to pollute a real branch with crap. I know how to rewrite history getting rid of it all, but I’d rather not. I prefer a bright line between tested, quality work with messages ready for review, and whatever I happened to be in the middle of (that I may or may not decide to abandon later).
  - scubbo 3y ago
    Fair enough! Just for the purposes of comparison - my own "bright line between [good and bad]" is "does the commit message just contain 'WIP', or is it actually fully written-out?" - but I can see that "is the work committed or not?" also works. Thanks for explaining!
    - erik_seaberg 3y ago
      What worries me about WIP commits is that dropping them via rebase -i might not be trivial if quality commits later depend on them.
      - scubbo 3y ago
        Certainly! That's (one reason) why I'd _never_ drop a commit while doing `rebase -i` - just squash everything into a single (well-written) commit once it's ready to be reviewed! On some _very_ rare occasions, I might find that, by the time I've gotten the change to a reviewable state, it's actually too large to be meaningfully reviewed in one go, in which case I'll go back and retroactively (re-)implement it reviewable-chunk-by-reviewable-chunk (on a different branch), and get each of them reviewed and merged in turn. But, 99% of the time, I simply: * use WIP commits as "checkpoints" along the way while implementing * get to a minimal mergable change * use `rebase -i` to squash everything into a single, well-written, reviewable commit * rinse and repeat

nerdponx 3y ago

There are many legitimate use cases for multiple worktrees. Here's one example: I'm working on a trunk-based project, and I am upgrading a core framework like Angular or Django. That's a fairly intrusive change that involves modifying some untracked on-disk artifacts, like node_modules/ and package lockfiles. Switching branches doesn't help me manage those artifacts, and might require a full teardown and rebuild of my dev environment each switch. Even if I maintain a meticulous commit history and never have uncommitted "WIP stuff" that I need to stash, switching from my branch to fix a bug in the main branch could be annoying and intrusive just because of the dev environment. This is a great case for a separate worktree.

tomjakubowski 3y ago
Yep, just added similar thoughts myself.

tomjakubowski 3y ago

There's another case where worktrees are great, whether or not you are compensating for other problems. If your project's build takes forever, but incremental builds are relatively fast, worktrees are a good way to preserve build state on the file system between branch switches.

coldtea 3y ago
>worktrees are a good way to preserve build state on the file system between branch switches. Why would you ever have build artifacts, incremental or not, as part of your code repo?
- neandrake 3y ago
  It’s probably not part of their repo, but exists alongside, possibly gitignored. Either way in the same workspace the IDE will have to invalidate a lot of it when you switch, and again so when switching back. Separate clones, or worktrees, mean they don’t get invalidated and your IDE just sees them as a separate project altogether, each with its own cache, regardless of where that cache exists.

kraftman 3y ago

Why not commit what you have and ammend / rebase it later?

mabster 3y ago

I picked up my git workflow from a very commit-centric workplace. Instead of stashing or anything like that we would commit with the text "WIP". Every time we had a stable point, we would make a "WIP" commit and then continue, giving us a good point to revert to if the next steps don't work. If someone interrupts me I would make a WIP commit and then revert it and then make the change they're asking about. Later on we would squash the WIP commits and make real commits out of the changes. Another nice thing about this workflow is that everything goes into the reflog.

avgcorrection 3y ago
This is the way. Just commit. You can undo it later or whatever, but at least it’s there. Just one concept instead of (1) commits (2) stash (3) oh these changes, eh, I don’t know what to do with them... let’s think about it after lunch.

scubbo 3y ago

> For me it's because, for whatever reason, I don't want to commit my shitty in progress work right now This is kind-of the million dollar question, though, I think? What would such a reason be? (I ask from a perspective of genuine curiosity, not of implying that you're wrong to have them)

erik_seaberg 3y ago
I don’t want to pollute a real branch with crap. I know how to rewrite history getting rid of it all, but I’d rather not. I prefer a bright line between tested, quality work with messages ready for review, and whatever I happened to be in the middle of (that I may or may not decide to abandon later).
- scubbo 3y ago
  Fair enough! Just for the purposes of comparison - my own "bright line between [good and bad]" is "does the commit message just contain 'WIP', or is it actually fully written-out?" - but I can see that "is the work committed or not?" also works. Thanks for explaining!
  - erik_seaberg 3y ago
    What worries me about WIP commits is that dropping them via rebase -i might not be trivial if quality commits later depend on them.
    - scubbo 3y ago
      Certainly! That's (one reason) why I'd _never_ drop a commit while doing `rebase -i` - just squash everything into a single (well-written) commit once it's ready to be reviewed! On some _very_ rare occasions, I might find that, by the time I've gotten the change to a reviewable state, it's actually too large to be meaningfully reviewed in one go, in which case I'll go back and retroactively (re-)implement it reviewable-chunk-by-reviewable-chunk (on a different branch), and get each of them reviewed and merged in turn. But, 99% of the time, I simply: * use WIP commits as "checkpoints" along the way while implementing * get to a minimal mergable change * use `rebase -i` to squash everything into a single, well-written, reviewable commit * rinse and repeat