{"thread":{"id":"33993","subject":"preventing evil merges","startedAt":"2013-05-30T16:34:59Z","lastAt":"2013-06-03T17:37:00Z","messageCount":3,"participants":["Sandro Santilli","Junio C Hamano","Antoine Pelisse"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219029","messageId":"20130530163459.GI31679@gnash","threadId":"33993","inReplyTo":null,"subject":"preventing evil merges","fromName":"Sandro Santilli","fromEmail":"strk@keybit.net","sentAt":"2013-05-30T16:34:59Z","receivedAt":"2013-05-30T16:34:59Z","isPatch":false,"sender":{"key":"strk@keybit.net","avatar":"https://gravatar.com/avatar/9a6c11d66829bf429efe5ef4c066d50272394481cc3f8ae8116a006c81dc6cf9?d=mp&s=160"},"body":"Hey all,\nI've be burnt by what someone on IRC referred to as \"evil merges\",\nthat is loss of history after amending a merge commit:\n\n git merge anotherbranch\n git add something\n git commit --amend\n\nAfter the steps above the addition of \"something\" can't be found in\nthe history anymore, but the file is there. Moreover (I think but\ndidn't try to reproruce) a further rebase to a common ancestore of\nmy working branch and \"anotherbranch\" resulted in further loss of\nthe changes. The only way for me to get them back has been by \nchecking out from reflog.\n\nI've no idea about what was going on but this experience reminded me\nof another one I had in the past in which we could not figure out when\nsome changes were added into a repository (!).\n\nIf amending a merge is so dangerous, would it make sense to require\nand hard-to-type switch in order for it to really do anything ?\n\n--strk; \n"},{"id":"219248","messageId":"7vvc5vglh5.fsf@alter.siamese.dyndns.org","threadId":"33993","inReplyTo":"20130530163459.GI31679@gnash","subject":"Re: preventing evil merges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-03T17:20:06Z","receivedAt":"2013-06-03T17:20:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sandro Santilli <strk@keybit.net> writes:\n\n>  git merge anotherbranch\n>  git add something\n>  git commit --amend\n>\n> After the steps above the addition of \"something\" can't be found in\n> the history anymore, but the file is there.\n\nThis is a very common and sensible thing to do when dealing with\nsemantic conflict.  Imagine that you changed the name of a global\nvariable in the code on your current branch since the anotherbranch\nyou are pulling from forked from you.  Then imagine further that the \nanotherbranch added one location that refers to that variable.\n\nSince they are not aware of the name change, they added the new\nreference with the old variable name.  The part they added is a new\ncode, so it is very likely that there is no textual conflict when\nyou did \"git merge anotherbranch\".  But now the result is broken.\n\nAnd you fix that semantic conflict by editing the file they added\nthe new reference to the variable under the old name and make it use\nthe variable with the new name.  You \"git add something\" and amend\nthe merge.\n\n\"git show\" of the result will show you what happened, I think.\n"},{"id":"219255","messageId":"CALWbr2yLHN7VgPhH-HvyBx04pHasH=zr6fTXtjjsKJgqHA8kKQ@mail.gmail.com","threadId":"33993","inReplyTo":"7vvc5vglh5.fsf@alter.siamese.dyndns.org","subject":"Re: preventing evil merges","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-06-03T17:37:00Z","receivedAt":"2013-06-03T17:37:00Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Sandro Santilli <strk@keybit.net> writes:\n>\n>>  git merge anotherbranch\n>>  git add something\n>>  git commit --amend\n>>\n>> After the steps above the addition of \"something\" can't be found in\n>> the history anymore, but the file is there.\n>\n> This is a very common and sensible thing to do when dealing with\n> semantic conflict.  Imagine that you changed the name of a global\n> variable in the code on your current branch since the anotherbranch\n> you are pulling from forked from you.  Then imagine further that the\n> anotherbranch added one location that refers to that variable.\n>\n> Since they are not aware of the name change, they added the new\n> reference with the old variable name.  The part they added is a new\n> code, so it is very likely that there is no textual conflict when\n> you did \"git merge anotherbranch\".  But now the result is broken.\n>\n> And you fix that semantic conflict by editing the file they added\n> the new reference to the variable under the old name and make it use\n> the variable with the new name.  You \"git add something\" and amend\n> the merge.\n>\n> \"git show\" of the result will show you what happened, I think.\n\nAlso, you need to use --cc option of log to see the change in history\n(in addition to -p):\n\n    git log --cc -p\n"}]}