There shouldn't be a cherry pick involved, and my protip would be that you don't actually need to make a local branch for small changes; quite often I'll just do `git checkout origin/master`, make the fix, commit, and `git push mine HEAD:refs/heads/quickfix`. But yeah, it would be nice to have a way to just commit a diff at a different point in history without having to check it out.
> There is if you discover the typo in the middle of working on something else, which is usually the case for me.
Why/how? If I had other uncommitted changes when I found the typo I'd stash or commit them so that I had a clean checkout to do the typo fix from, but can't think of any case where cherry pick is the right answer.
Yeah, but I find that can be pretty disruptive to my flow. You have to:
1. Switch from your editor to a shell
2. Stash
3. Switch from your shell back to your editor
4. Revert the editor buffer
5. Fix the typo
6. Save
7. Switch back to your shell
8. Commit
Now you have to push that fix into all the upstream branches (because the whole point of this exercise is to avoid merge commits from someone else fixing the same typo), so:
9. Checkout
10. Pull
11. Merge the typo fix (at which point you might discover that someone else has already fixed this typo, or that you have an actual conflict that needs to be dealt with)
12. Commit
13. Push (at which point you might discover that someone else was in the process of fixing the same typo and just happened to push before you did. This is unlikely, but it becomes more likely the longer you wait between step 10 and 11 because there is a race condition here.)
14. Repeat for every upstream branch in which anyone could have already fixed the same typo
Then, finally:
N. Stash pop
N+1. Switch back to your editor
N+2. Revert your editor buffer
N+3. Try to remember what you were working on before you started this process.
It's a hell of a lot easier to just fix the typo and say, "ah, fuck it", and then curse at git for not being smart enough to figure out that identical changes aren't conflicts. ;-)
> Yeah, but I find that can be pretty disruptive to my flow.
Well, I think it's very much worth having git support integrated into your editing tool, so for me the workflow is more:
1. Shelve current changes, if any
2. (Optional) fetch origin
3. Switch branch
4. Make the fix
5. Commit-push
6. Merge this branch upstream
7. Switch branch back
8. Pull upstream master
9. Unshelve if necessary
I wouldn't consider it my responsibility to apply the fix to anyone else's branch - rather every branch has an owner and it's their responsibility to update from origin master at whatever frequency suits them - and if someone else has fixed the problem in parallel then either I notice at stage 4, or, if they did it in between me reaching 2 and me reaching 6 then 6 fails harmlessly (I just continue to 7 and 8 and I pick up their version of the fix, no need to resolve any conflict). This does rely on having a single shared "origin master" (whether that's your git hosting system, your release manager's machine, or something else) that can do step 6 atomically - if you really want a 100% decentralised system then yeah the price of that is eventual consistency.
All that said, git merge absolutely does treat a byte-for-byte identical change as not a conflict (I just confirmed with git merge-file), and will treat an identical-except-for-whitespace fix as not a conflict if you pass it the appropriate flags, so I think something else must be going on to cause the problem you're seeing.
> I wouldn't consider it my responsibility to apply the fix to anyone else's branch
I guess my situation is a bit unusual. We have two production branches because we're running our code in two different environments. So we have two branches that are effectively origin/masters.
> git merge absolutely does treat a byte-for-byte identical change as not a conflict
That's news to me. I guess I'll have to try that again because I have a very clear memory of seeing this happen and thinking WTF? But that could have been a long time ago.
