[coldtea]

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]

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.

[avgcorrection]

“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]

> 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]

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.

[robertlagrant]

> And using these extra concepts on top of (or under?) Git doesn’t make sense for my workflow

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.

[coldtea]

>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.