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