Re: "Losing" MERGE_HEAD

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