5 ms·

> 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

> 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.
- MaulingMonkey 3y ago
  > "commit your halfway feature work/.../come back to the feature and amend/squash/soft reset" ...this is just by-hand stashing with alternative commands and extra "WIP" commit messages. Which, uh, is admittedly an option. One that won't easily preserve your index independently from your working tree - awkward if you're in the middle of painstakingly separating out changes to add to the next commit with `git add -p` - and one that risks "WIP" commits ending up in your tree... but it is an option.
  - avgcorrection 3y ago
    IMO you don’t need anything more than commits. The by-hand is writing WIP in the commit message. If that is an inconvenience then I’ll make a commit alias. The index + commits is flexible enough. The stash concept is not needed for me. See: https://news.ycombinator.com/item?id=39606525 https://news.ycombinator.com/item?id=39606525
- avgcorrection 3y ago
  I think that you (like me) prefer to use commits in places where many others prefer to stash. Personally I think the stash command is too primitive to bother with for all things except maybe an push+pop that happens within half a minute. Anything more and I risk forgetting about it. A WIP commit however is just there, on the branch, for me to deal with however I want later. I don’t want to fiddle with dropping the stash one too many times, forgetting what they were about and so on. Merge conflicts because I didn’t pop before resuming.. It’s just a mostly useless additional “thing”.
  - avgcorrection 3y ago
    Amendment: I just found out that I do have at least one use for git-stash, which is when I am stuck in the middle of a rebase somewhere and made an edit intended for another point (commit).

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.

MaulingMonkey 3y ago
> "commit your halfway feature work/.../come back to the feature and amend/squash/soft reset" ...this is just by-hand stashing with alternative commands and extra "WIP" commit messages. Which, uh, is admittedly an option. One that won't easily preserve your index independently from your working tree - awkward if you're in the middle of painstakingly separating out changes to add to the next commit with `git add -p` - and one that risks "WIP" commits ending up in your tree... but it is an option.
- avgcorrection 3y ago
  IMO you don’t need anything more than commits. The by-hand is writing WIP in the commit message. If that is an inconvenience then I’ll make a commit alias. The index + commits is flexible enough. The stash concept is not needed for me. See: https://news.ycombinator.com/item?id=39606525 https://news.ycombinator.com/item?id=39606525
avgcorrection 3y ago
I think that you (like me) prefer to use commits in places where many others prefer to stash. Personally I think the stash command is too primitive to bother with for all things except maybe an push+pop that happens within half a minute. Anything more and I risk forgetting about it. A WIP commit however is just there, on the branch, for me to deal with however I want later. I don’t want to fiddle with dropping the stash one too many times, forgetting what they were about and so on. Merge conflicts because I didn’t pop before resuming.. It’s just a mostly useless additional “thing”.
- avgcorrection 3y ago
  Amendment: I just found out that I do have at least one use for git-stash, which is when I am stuck in the middle of a rebase somewhere and made an edit intended for another point (commit).