Bryan TurnerI was looking through the commit history in a repository I work in and I found a place where someone had created a merge, but somewhere between "git merge" and "git commit" the fact that it was a merge was "lost". Instead they ended up with a really big commit that applied all the changes from the merged-in branch.
A really easy way to reproduce this is: git merge master #Assume this has conflicts, or use --no-commit git checkout -b some-new-branch
When the checkout runs, MERGE_HEAD et al are deleted without any sort of warning, but the uncommitted changes are not lost. If a user then runs "git commit", and doesn't notice that there's no helpful "It looks like you may be committing a merge", they'll create a new, non-merge commit that essentially reapplies all the changes they merged in.
I'm pretty familiar with Git and I make this mistake at least a few times a year. So far I've always caught it during the commit, though. Unfortunately, in this case, the bad "merge" wasn't noticed before it made its way to master, so now it's there for good.
I'm not sure what there is to do about this. It's clear it's a long-standing behavior. One approach might be to introduce a warning when changing branches deletes MERGE_*. A different one might be to fail to change branches without something like --force. I'm not sure either is _better_ than the current behavior, but they're certainly _clearer_. That said, perhaps this behavior is something someone relies on.
Best regards, Bryan Turner
