{"thread":{"id":"51204","subject":"\"Losing\" MERGE_HEAD","startedAt":"2019-05-31T04:17:23Z","lastAt":"2019-05-31T06:03:27Z","messageCount":2,"participants":["Bryan Turner","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"376465","messageId":"CAGyf7-EgiWtt0xu9nfYdhafZ6D70nSxbNYAguFrN8OWRqWmzGQ@mail.gmail.com","threadId":"51204","inReplyTo":null,"subject":"\"Losing\" MERGE_HEAD","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2019-05-31T04:16:56Z","receivedAt":"2019-05-31T04:17:23Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"I was looking through the commit history in a repository I work in and\nI found a place where someone had created a merge, but somewhere\nbetween \"git merge\" and \"git commit\" the fact that it was a merge was\n\"lost\". Instead they ended up with a really big commit that applied\nall the changes from the merged-in branch.\n\nA really easy way to reproduce this is:\ngit merge master #Assume this has conflicts, or use --no-commit\ngit checkout -b some-new-branch\n\nWhen the checkout runs, MERGE_HEAD et al are deleted without any sort\nof warning, but the uncommitted changes are not lost. If a user then\nruns \"git commit\", and doesn't notice that there's no helpful \"It\nlooks like you may be committing a merge\", they'll create a new,\nnon-merge commit that essentially reapplies all the changes they\nmerged in.\n\nI'm pretty familiar with Git and I make this mistake at least a few\ntimes a year. So far I've always caught it during the commit, though.\nUnfortunately, in this case, the bad \"merge\" wasn't noticed before it\nmade its way to master, so now it's there for good.\n\nI'm not sure what there is to do about this. It's clear it's a\nlong-standing behavior. One approach might be to introduce a warning\nwhen changing branches deletes MERGE_*. A different one might be to\nfail to change branches without something like --force. I'm not sure\neither is _better_ than the current behavior, but they're certainly\n_clearer_. That said, perhaps this behavior is something someone\nrelies on.\n\nBest regards,\nBryan Turner\n"},{"id":"376467","messageId":"CABPp-BHramOjqpH0Rz-PEKbi0TX_sKOYvLiZ2Pb=hEpViaShmw@mail.gmail.com","threadId":"51204","inReplyTo":"CAGyf7-EgiWtt0xu9nfYdhafZ6D70nSxbNYAguFrN8OWRqWmzGQ@mail.gmail.com","subject":"Re: \"Losing\" MERGE_HEAD","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-05-31T06:03:13Z","receivedAt":"2019-05-31T06:03:27Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, May 30, 2019 at 9:19 PM Bryan Turner <bturner@atlassian.com> wrote:\n>\n> I was looking through the commit history in a repository I work in and\n> I found a place where someone had created a merge, but somewhere\n> between \"git merge\" and \"git commit\" the fact that it was a merge was\n> \"lost\". Instead they ended up with a really big commit that applied\n> all the changes from the merged-in branch.\n>\n> A really easy way to reproduce this is:\n> git merge master #Assume this has conflicts, or use --no-commit\n> git checkout -b some-new-branch\n>\n> When the checkout runs, MERGE_HEAD et al are deleted without any sort\n> of warning, but the uncommitted changes are not lost. If a user then\n> runs \"git commit\", and doesn't notice that there's no helpful \"It\n> looks like you may be committing a merge\", they'll create a new,\n> non-merge commit that essentially reapplies all the changes they\n> merged in.\n>\n> I'm pretty familiar with Git and I make this mistake at least a few\n> times a year. So far I've always caught it during the commit, though.\n> Unfortunately, in this case, the bad \"merge\" wasn't noticed before it\n> made its way to master, so now it's there for good.\n>\n> I'm not sure what there is to do about this. It's clear it's a\n> long-standing behavior. One approach might be to introduce a warning\n> when changing branches deletes MERGE_*. A different one might be to\n> fail to change branches without something like --force. I'm not sure\n> either is _better_ than the current behavior, but they're certainly\n> _clearer_. That said, perhaps this behavior is something someone\n> relies on.\n>\n> Best regards,\n> Bryan Turner\n\nDiscussed in detail recently starting at\nhttps://public-inbox.org/git/CACsJy8Axa5WsLSjiscjnxVK6jQHkfs-gH959=YtUvQkWriAk5w@mail.gmail.com/\n\nresulting in\nhttps://public-inbox.org/git/20190329103919.15642-8-pclouds@gmail.com/\nand\nhttps://public-inbox.org/git/20190329103919.15642-24-pclouds@gmail.com/\n\nI think we should still do the follow up for checkout, as mentioned at\nhttps://public-inbox.org/git/CABPp-BHX1gRhTdurAwrPg60Hk-OuhbrEN=4zatx4OOUo-DkQvw@mail.gmail.com/\n\nIt's good to get extra feedback that this isn't just theoretical but\nis causing people actual problems.  Do you want to take the time to\nmake the change I suggested in the last email above and propose it to\nthe list?  I think the main thing needed is just a good commit message\nand getting feedback and thoughts from others; your description above\nwas well written and I'm busy on other things right now, so if you'd\nlike to tackle it, I'd appreciate it.  If not, I will hopefully\nremember to get back to it eventually.\n\nHope that helps,\nElijah\n"}]}