[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: "Losing" MERGE_HEAD
From:       Elijah Newren <newren () gmail ! com>
Date:       2019-05-31 6:03:13
Message-ID: CABPp-BHramOjqpH0Rz-PEKbi0TX_sKOYvLiZ2Pb=hEpViaShmw () mail ! gmail ! com
[Download RAW message or body]

On Thu, May 30, 2019 at 9:19 PM Bryan Turner <bturner@atlassian.com> wrote:
>
> 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

Discussed in detail recently starting at
https://public-inbox.org/git/CACsJy8Axa5WsLSjiscjnxVK6jQHkfs-gH959=YtUvQkWriAk5w@mail.gmail.com/

resulting in
https://public-inbox.org/git/20190329103919.15642-8-pclouds@gmail.com/
and
https://public-inbox.org/git/20190329103919.15642-24-pclouds@gmail.com/

I think we should still do the follow up for checkout, as mentioned at
https://public-inbox.org/git/CABPp-BHX1gRhTdurAwrPg60Hk-OuhbrEN=4zatx4OOUo-DkQvw@mail.gmail.com/

It's good to get extra feedback that this isn't just theoretical but
is causing people actual problems.  Do you want to take the time to
make the change I suggested in the last email above and propose it to
the list?  I think the main thing needed is just a good commit message
and getting feedback and thoughts from others; your description above
was well written and I'm busy on other things right now, so if you'd
like to tackle it, I'd appreciate it.  If not, I will hopefully
remember to get back to it eventually.

Hope that helps,
Elijah
[prev in list] [next in list] [prev in thread] [next in thread]