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.
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.
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.
(Again this is what git-reset(1) and friends are for)
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.
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.
I think this is the key comment - that might be true, but I don't see a real criticism of making tools for not-avgcorrection to facilitate their workflows better. I agree things can be done in Git. I disagree that they must be done in Git.
Why not just commit it?
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).
> 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!