3 ms·

>Let's take an example. Let's say you are working on a feature. Your boss interrupts you (, bosses, right?) and says "we need this bug fixed". Or maybe you just

>Let's take an example. Let's say you are working on a feature. Your boss interrupts you (, bosses, right?) and says "we need this bug fixed". Or maybe you just notice the bug as you're working. Whatever it is, you need to switch contexts while in the middle of something. Now you have a few options. - You can fix the bug and commit it into your feature branch and try to get them both deployed together. - You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. - You could locally clone the repository to a new directory and work on the other branch there, then push it back into the main one and then push from there back upstream. -- What? Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? Then when one of the two (bugfix or feature branch) is merged into main, you rebase main into the other.

deleted 3y ago
[deleted]
corytheboyd 3y ago
Completely agreed, this is pretty basic git that I would expect experienced developers to have down. This isn’t even a UI vs CLI argument, it’s the same idea in either case. I’ll keep an open mind, but if you’re going to shake up a workflow as solid and well understood as git, you better have a damn good offering.
Huggernaut 3y ago
I don't particularly care either way but how is that meaningfully different from option 2? You need to do something with your WIP in either case before switching to the new branch.
- coldtea 3y ago
  Well, stashing is ok for short term context switch, but it's not that organized or neat. You're supposed to be working in a feature branch when your were given the bug to fix. Would you not have commited (or, worse, pushed) anything to it already? Most times you already have, so it's not like stashing your latest changes and getting to the latest state of the feature branch is neutral. Plus, what big benefit would stashing have, since you'll still need to create a separate bugfix branch to create the bugfix PR off anyway? If you get to context switch while you were working on my-feature-branch, you still need to create my-bugfix-branch and push the fix from that, no? Besides nobody guarantees you ahead of time that the bug will just be solved fast and they get to return to working on the feature pronto. So a bugfix branch makes more sense than a stash, which is more of a short term thing. Just making a bugfix branch is neater.
  - robertlagrant 3y ago
    You might not be in a position to commit. You could commit just what you have, make a bugfix branch, and then when you return to your original branch do a git reset later back to the uncommitted state. It just isn't that neat.
    - coldtea 3y ago
      >You might not be in a position to commit So? That's what amend and/or squash is for. So that you don't need to be in some "perfect" condition to commit. Or you can do a soft git reset as you say. But sure, even git stash would make more sense than worktrees for the TFA scenario I quoted.
    - avgcorrection 3y ago
      “Not in a position to commit” in Git makes as much sense as “not in a position to save the file” (in your editor) in 2024. Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state. (Again this is what git-reset(1) and friends are for)
      - robertlagrant 3y ago
        > Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state. Git might be, but how many people want to use git is to provide useful commit histories, both for any reviewers at the time and any code spelunkers 10 years into the future. Having a tool that tries to make that easier isn't a bad idea.
        avgcorrection 3y ago
        My comment was totally unclear. By primitive I mean that it scales from very primitive operations (just snapshot) to supporting high-level workflows (refactoring, testing, verifying). And by primitive I mean that I want to be able to commit whenever I feel like I want a snapshot. For any reason. Not hindered by concepts like does-it-build. That’s the low level. Then at the higher level are things like “public history” and “tested history”. That’s facilitated by the low/mid-level history rewriting tools. Some people I know use Intellij’s “shelve” feature or whatever it is called. Interestingly it does provide some features that Git does not seem to have—and overlaps with GitButler—but it’s own bespoke thing, not integrated with Git. And using these extra concepts on top of (or under?) Git doesn’t make sense for my workflow. Because the VCS is already there. So I don’t need to think about if I’m ready-to-commit—just make a WIP or a TEST commit, maybe discard later or maybe rewrite them. For me, Git covers everything from snapshotting some private notes I have on the work that I’m currently doing to making a nice: > useful commit [history], both for any reviewers at the time and any code spelunkers 10 years into the future. It provides that whole range.
- marcellus23 3y ago
  > You need to do something with your WIP in either case Why not just commit it?
  - Huggernaut 3y ago
    Sure. In terms of steps taken it's not particularly different though. Stash at the start and pop at the end vs commit at the start and reset at the end, right? I mean, if it's not a problem to do that (and I don't find either option a problem personally) then fine, but it doesn't seem like it's a "better" option except in some small cases (like forgetting you stashed).
    - opium_tea 3y ago
      I'm so confused. Blog author said this: > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. And OP said this (snarkily) > Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? They're the same except the blog author was more specific!
tomjakubowski 3y ago
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?
txg 3y ago
If you want to run some time-consuming tests prior to pushing your bug fix it's convenient to run those in your separate worktree. You can continue working on your original branch while the tests run.
- XorNot 3y ago
  The article starts out by talking about the built in git worktree command which will do this for you, and is built into git already.[1] The question is, if that exists why are the virtual trees meaningfully different? [1] https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
MaulingMonkey 3y ago
> Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? I mean, that's option 2 of what you're quoting, and is generally my preferred option. That said, there are cases where it breaks down and I end up wanting worktrees or independent clones, generally involving ≈`.gitignore`d local data: • A newly created bugfixing branch may take awhile (minutes? hours?) for me to build. I can either go on a coffee break while waiting for it (since I can't very well test my ability to reproduce the bug, nor verify my bugfixes work, without having said branch in a compiling state), or I can have said build occur in a secondary worktree - and continue working on my original task in my primary worktree while waiting for it to build. • If I've got a lot of `.gitignore`d config file tweaks related to my major feature work / profiling / debugging / ???, I might not want to bring those over to my bugfixing session. `git stash push --all` is an option, but that will get build artifacts - which will take awhile to stash - not just my local config files. A fun ancedote: I once wasted an hour failing to reproduce a game's audio crash because a local `user.ini` file had the entire audio system disabled via feature flag. (I now prefer setting the volume to 0 instead.) • I do a bunch of porting and cross-platform abstraction stuff, which makes my build times even worse than usual by having to repeat builds N times. I might not want to invalidate by main build cache for all that, when my bugfixing branch might only reasonably need local testing on 1 platform, and gain next to no benefit from the previous cache as is (depending on how far diverged the branch I was working from and the branch where the bugfix should occur are.)
- coldtea 3y ago
  >I mean, that's option 2 of what you're quoting, No, option 2 is to stash. Their three weird options are: (a) fix the bug on the feature branch and "try to get them both deployed together" (b) git stash, fix the bug in a new branch, come back (c) locally clone the repository At least (b) is somewhat sane, but it's still weird that the even more code-managementy option of "commit your halfway feature work/create new branch for the bugfix/come back to the feature and amend/squash/soft reset" isn't even mentioned. Your cases are more involved than the contrived scenario you give, where their weird options don't make sense.
  - 3y ago
majikandy 3y ago
This is word for word what I was about to write. Totally agree as I had a very puzzled face when that option didn’t appear in the list. And even more puzzled when (what I thought was the throwaway flippant idea of) ‘cloning the repo into another folder’ was in the list. I can safely say, I’ve never done this and can’t think of a scenario where I would need to.
- opium_tea 3y ago
  How is it different from the second bullet point? Except the second bullet point is more specific in that it says what to do with uncommitted changes.
  - coldtea 3y ago
    >How is it different from the second bullet point? How "cloning the repo on a different folder on the same machine just to work on a bug fix" is different from the main way Git is supposed to be used (creating a new branch for the bug fix and working there, then checking out your feature branch again)? In that it doesn't make sense. They might as well go full 1980s style "codebase_1/ codebase_2/ codebase_3/ codebase_3.bak/" and so on copies, and skip code management altogether...
    - opium_tea 3y ago
      That's the third bullet point. I was talking about this one: > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. OP said this (you and a few others reiterated or agreed with it) > Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? I can't see the difference. Seeing them side by side they're virtually identical except the blog author specified stashing!
avgcorrection 3y ago
You don’t have to interpret it as you-always-do-this. Just sometimes you want a worktree (or clone): maybe the bug fix needs to be applied to an old, old release which would invalidate all the indexes in your project. So then you can make a worktree so that your main worktree is left in peace. But is it overkill for some fast translation fixes? Yeah, probably:)

deleted 3y ago

[deleted]

corytheboyd 3y ago

Completely agreed, this is pretty basic git that I would expect experienced developers to have down. This isn’t even a UI vs CLI argument, it’s the same idea in either case. I’ll keep an open mind, but if you’re going to shake up a workflow as solid and well understood as git, you better have a damn good offering.

Huggernaut 3y ago

I don't particularly care either way but how is that meaningfully different from option 2? You need to do something with your WIP in either case before switching to the new branch.

coldtea 3y ago
Well, stashing is ok for short term context switch, but it's not that organized or neat. You're supposed to be working in a feature branch when your were given the bug to fix. Would you not have commited (or, worse, pushed) anything to it already? Most times you already have, so it's not like stashing your latest changes and getting to the latest state of the feature branch is neutral. Plus, what big benefit would stashing have, since you'll still need to create a separate bugfix branch to create the bugfix PR off anyway? If you get to context switch while you were working on my-feature-branch, you still need to create my-bugfix-branch and push the fix from that, no? Besides nobody guarantees you ahead of time that the bug will just be solved fast and they get to return to working on the feature pronto. So a bugfix branch makes more sense than a stash, which is more of a short term thing. Just making a bugfix branch is neater.
- robertlagrant 3y ago
  You might not be in a position to commit. You could commit just what you have, make a bugfix branch, and then when you return to your original branch do a git reset later back to the uncommitted state. It just isn't that neat.
  - coldtea 3y ago
    >You might not be in a position to commit So? That's what amend and/or squash is for. So that you don't need to be in some "perfect" condition to commit. Or you can do a soft git reset as you say. But sure, even git stash would make more sense than worktrees for the TFA scenario I quoted.
  - avgcorrection 3y ago
    “Not in a position to commit” in Git makes as much sense as “not in a position to save the file” (in your editor) in 2024. Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state. (Again this is what git-reset(1) and friends are for)
    - robertlagrant 3y ago
      > Git is in a sense a primitive tool: only about snapshotting, not about high-falutin things like “passes the tests”, “is okay with Bob”, and so on. It’s just about tracking state. Git might be, but how many people want to use git is to provide useful commit histories, both for any reviewers at the time and any code spelunkers 10 years into the future. Having a tool that tries to make that easier isn't a bad idea.
      - avgcorrection 3y ago
        My comment was totally unclear. By primitive I mean that it scales from very primitive operations (just snapshot) to supporting high-level workflows (refactoring, testing, verifying). And by primitive I mean that I want to be able to commit whenever I feel like I want a snapshot. For any reason. Not hindered by concepts like does-it-build. That’s the low level. Then at the higher level are things like “public history” and “tested history”. That’s facilitated by the low/mid-level history rewriting tools. Some people I know use Intellij’s “shelve” feature or whatever it is called. Interestingly it does provide some features that Git does not seem to have—and overlaps with GitButler—but it’s own bespoke thing, not integrated with Git. And using these extra concepts on top of (or under?) Git doesn’t make sense for my workflow. Because the VCS is already there. So I don’t need to think about if I’m ready-to-commit—just make a WIP or a TEST commit, maybe discard later or maybe rewrite them. For me, Git covers everything from snapshotting some private notes I have on the work that I’m currently doing to making a nice: > useful commit [history], both for any reviewers at the time and any code spelunkers 10 years into the future. It provides that whole range.
marcellus23 3y ago
> You need to do something with your WIP in either case Why not just commit it?
- Huggernaut 3y ago
  Sure. In terms of steps taken it's not particularly different though. Stash at the start and pop at the end vs commit at the start and reset at the end, right? I mean, if it's not a problem to do that (and I don't find either option a problem personally) then fine, but it doesn't seem like it's a "better" option except in some small cases (like forgetting you stashed).
  - opium_tea 3y ago
    I'm so confused. Blog author said this: > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. And OP said this (snarkily) > Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? They're the same except the blog author was more specific!

tomjakubowski 3y ago

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?

txg 3y ago

If you want to run some time-consuming tests prior to pushing your bug fix it's convenient to run those in your separate worktree. You can continue working on your original branch while the tests run.

XorNot 3y ago
The article starts out by talking about the built in git worktree command which will do this for you, and is built into git already.[1] The question is, if that exists why are the virtual trees meaningfully different? [1] https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree

MaulingMonkey 3y ago

> Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? I mean, that's option 2 of what you're quoting, and is generally my preferred option. That said, there are cases where it breaks down and I end up wanting worktrees or independent clones, generally involving ≈`.gitignore`d local data: • A newly created bugfixing branch may take awhile (minutes? hours?) for me to build. I can either go on a coffee break while waiting for it (since I can't very well test my ability to reproduce the bug, nor verify my bugfixes work, without having said branch in a compiling state), or I can have said build occur in a secondary worktree - and continue working on my original task in my primary worktree while waiting for it to build. • If I've got a lot of `.gitignore`d config file tweaks related to my major feature work / profiling / debugging / ???, I might not want to bring those over to my bugfixing session. `git stash push --all` is an option, but that will get build artifacts - which will take awhile to stash - not just my local config files. A fun ancedote: I once wasted an hour failing to reproduce a game's audio crash because a local `user.ini` file had the entire audio system disabled via feature flag. (I now prefer setting the volume to 0 instead.) • I do a bunch of porting and cross-platform abstraction stuff, which makes my build times even worse than usual by having to repeat builds N times. I might not want to invalidate by main build cache for all that, when my bugfixing branch might only reasonably need local testing on 1 platform, and gain next to no benefit from the previous cache as is (depending on how far diverged the branch I was working from and the branch where the bugfix should occur are.)

coldtea 3y ago
>I mean, that's option 2 of what you're quoting, No, option 2 is to stash. Their three weird options are: (a) fix the bug on the feature branch and "try to get them both deployed together" (b) git stash, fix the bug in a new branch, come back (c) locally clone the repository At least (b) is somewhat sane, but it's still weird that the even more code-managementy option of "commit your halfway feature work/create new branch for the bugfix/come back to the feature and amend/squash/soft reset" isn't even mentioned. Your cases are more involved than the contrived scenario you give, where their weird options don't make sense.
- 3y ago

majikandy 3y ago

This is word for word what I was about to write. Totally agree as I had a very puzzled face when that option didn’t appear in the list. And even more puzzled when (what I thought was the throwaway flippant idea of) ‘cloning the repo into another folder’ was in the list. I can safely say, I’ve never done this and can’t think of a scenario where I would need to.

opium_tea 3y ago
How is it different from the second bullet point? Except the second bullet point is more specific in that it says what to do with uncommitted changes.
- coldtea 3y ago
  >How is it different from the second bullet point? How "cloning the repo on a different folder on the same machine just to work on a bug fix" is different from the main way Git is supposed to be used (creating a new branch for the bug fix and working there, then checking out your feature branch again)? In that it doesn't make sense. They might as well go full 1980s style "codebase_1/ codebase_2/ codebase_3/ codebase_3.bak/" and so on copies, and skip code management altogether...
  - opium_tea 3y ago
    That's the third bullet point. I was talking about this one: > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. OP said this (you and a few others reiterated or agreed with it) > Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? I can't see the difference. Seeing them side by side they're virtually identical except the blog author specified stashing!

avgcorrection 3y ago

You don’t have to interpret it as you-always-do-this. Just sometimes you want a worktree (or clone): maybe the bug fix needs to be applied to an old, old release which would invalidate all the indexes in your project. So then you can make a worktree so that your main worktree is left in peace. But is it overkill for some fast translation fixes? Yeah, probably:)