{"thread":{"id":"27775","subject":"Redoing a merge for a particular file","startedAt":"2011-07-07T22:24:10Z","lastAt":"2011-07-08T00:37:49Z","messageCount":5,"participants":["Chris Packham","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170997","messageId":"CAFOYHZCFetkokgtn4z0O3nPTEy6GCTEcN0Pzc8ce-joqMzZM1Q@mail.gmail.com","threadId":"27775","inReplyTo":null,"subject":"Redoing a merge for a particular file","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2011-07-07T22:24:10Z","receivedAt":"2011-07-07T22:24:10Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi All,\n\nI'm in the middle of merging to branches and I've screwed up my manual\nmerge, I've also got rerere enabled and I can't seem to get back into\na state to trigger git mergetool again.\n\n  $ git merge topic\n  ...\n  $ git mergetool\n  $ make\n  error: foo.c ... oops screwed up that merge.\n\nThe merge wasn't too painful so I don't mind starting again.\n\n  $ git reset --hard HEAD^\n  HEAD is now at 59c6097 ...\n  $ git merge topic\n  Auto-merging foo.c\n  CONFLICT (content): Merge conflict in foo.c\n  Auto-merging bar.c\n  CONFLICT (content): bar.c\n  Auto-merging otherfile1.c\n  Auto-merging otherfile2.c\n  Auto-merging otherfile3.c\n  Resolved 'foo.c' using previous resolution.\n  Resolved 'bar.c' using previous resolution.\n  Automatic merge failed; fix conflicts and then commit the result.\n  $ git mergetool\n  No files need merging\n\nSo rerere has remembered the bad resolution of foo.c.  But even if I\nrun 'git rerere clear' and repeat the above sequence I get the same\nresult. I seem to remember something like this coming up before.\nWasn't there an option added to checkout to allow us to recreate the\npre-merge state?\n\n  $ git checkout --merge foo.c\n  $ git mergetool\n  No files need merging\n\nI can manually fix the error and amend the merge commit I just thought\ngit should be able to give me some help. I could have sworn that\ncheckout --merge is the right thing to do. Sure enough the man page\nsays it is \"When checking out paths from the index, this option lets\nyou recreate the conflicted merge in the specified paths.\" maybe this\nis a bug?\n\nLooking at git status I think checkout is working as advertised but\nmaybe the bug is with mergetool.\n\n  $ git status\n  # On branch master\n  # Your branch is behind 'origin/master' by 1 commit, and can be\nfast-forwarded.\n  #\n  # Changes to be committed:\n  ....\n  # Unmerged paths:\n  #   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n  #\n  #\tboth modified:      foo.c\n  #\n\nfoo.c now does have conflict markers in it so I think it's crying out\nto be re-merged I just can't convince mergetool to do it. Am I doing\nsomething wrong?\n\nThanks,\nChris\n\nP.S.\n  $ git --version\n  git version 1.7.5.4\n"},{"id":"171001","messageId":"20110707224114.GA23273@sigill.intra.peff.net","threadId":"27775","inReplyTo":"CAFOYHZCFetkokgtn4z0O3nPTEy6GCTEcN0Pzc8ce-joqMzZM1Q@mail.gmail.com","subject":"Re: Redoing a merge for a particular file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-07T22:41:15Z","receivedAt":"2011-07-07T22:41:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 08, 2011 at 10:24:10AM +1200, Chris Packham wrote:\n\n> I'm in the middle of merging to branches and I've screwed up my manual\n> merge, I've also got rerere enabled and I can't seem to get back into\n> a state to trigger git mergetool again.\n> \n>   $ git merge topic\n>   ...\n>   $ git mergetool\n>   $ make\n>   error: foo.c ... oops screwed up that merge.\n> \n> The merge wasn't too painful so I don't mind starting again.\n> \n>   $ git reset --hard HEAD^\n>   HEAD is now at 59c6097 ...\n>   $ git merge topic\n>   Auto-merging foo.c\n>   CONFLICT (content): Merge conflict in foo.c\n>   Auto-merging bar.c\n>   CONFLICT (content): bar.c\n>   Auto-merging otherfile1.c\n>   Auto-merging otherfile2.c\n>   Auto-merging otherfile3.c\n>   Resolved 'foo.c' using previous resolution.\n>   Resolved 'bar.c' using previous resolution.\n>   Automatic merge failed; fix conflicts and then commit the result.\n>   $ git mergetool\n>   No files need merging\n> \n> So rerere has remembered the bad resolution of foo.c.  But even if I\n> run 'git rerere clear' and repeat the above sequence I get the same\n> result.\n\nI think you actually want \"rerere forget\". Like:\n\n  $ git reset --hard HEAD^\n  $ git merge topic\n  $ git rerere forget foo.c\n\nAlthough it is slightly more complicated if you have set\nrerere.autoupdate, since it will have cleared the index of any notion\nthat the path was conflicted. In that case you can then follow the\n\"rerere forget\" with:\n\n  $ git reset --hard\n  $ git merge topic\n\nto retry again.\n\nBut it doesn't look like you have autoupdate on, from the output above\n(it would say \"Staged 'foo.c'\" instead of \"Resolved 'foo.c\", I believe).\n\n> I seem to remember something like this coming up before.\n> Wasn't there an option added to checkout to allow us to recreate the\n> pre-merge state?\n> \n>   $ git checkout --merge foo.c\n>   $ git mergetool\n>   No files need merging\n\nIf you have rerere.autoupdate on, then it will have updated the index,\nand the path will not appear unmerged. You can use the trick above to\nget past it.\n\nIf you aren't using rerere.autoupdate (and haven't updated the index\nyourself), you shouldn't even need the \"git checkout --merge\" line. It\njust updates the working tree with the conflicted content, but mergetool\nwill operate directly on the original versions contained in the index,\nanyway.\n\n>   $ git status\n>   # On branch master\n>   # Your branch is behind 'origin/master' by 1 commit, and can be\n> fast-forwarded.\n>   #\n>   # Changes to be committed:\n>   ....\n>   # Unmerged paths:\n>   #   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n>   #\n>   #\tboth modified:      foo.c\n>   #\n> \n> foo.c now does have conflict markers in it so I think it's crying out\n> to be re-merged I just can't convince mergetool to do it. Am I doing\n> something wrong?\n\nHmm. That does seem like \"git checkout --merge\" did the right thing, but\nthat \"mergetool\" is wrong for not accepting it (it _should_ just be\nlooking at what's in the index to find unmerged paths).\n\nAhh. It is probably the fault of bb0a484 (mergetool: Skip autoresolved\npaths, 2010-08-17), which checks with rerere to avoid resolved paths. So\nI think:\n\n  $ git rerere forget foo.c\n  $ git mergetool\n\nwould do what you want.\n\n-Peff\n"},{"id":"171003","messageId":"CAFOYHZBBtqK2VtZ-Bq3uMAhGD4esSz7JDJn_4xaKb4y8wt9LJA@mail.gmail.com","threadId":"27775","inReplyTo":"20110707224114.GA23273@sigill.intra.peff.net","subject":"Re: Redoing a merge for a particular file","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2011-07-07T23:31:41Z","receivedAt":"2011-07-07T23:31:41Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Peff sorry for the spam. I forgot to CC the list.\n\nOn Fri, Jul 8, 2011 at 10:41 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Jul 08, 2011 at 10:24:10AM +1200, Chris Packham wrote:\n>\n>> I'm in the middle of merging to branches and I've screwed up my manual\n>> merge, I've also got rerere enabled and I can't seem to get back into\n>> a state to trigger git mergetool again.\n>>\n>>   $ git merge topic\n>>   ...\n>>   $ git mergetool\n>>   $ make\n>>   error: foo.c ... oops screwed up that merge.\n>>\n>> The merge wasn't too painful so I don't mind starting again.\n>>\n>>   $ git reset --hard HEAD^\n>>   HEAD is now at 59c6097 ...\n>>   $ git merge topic\n>>   Auto-merging foo.c\n>>   CONFLICT (content): Merge conflict in foo.c\n>>   Auto-merging bar.c\n>>   CONFLICT (content): bar.c\n>>   Auto-merging otherfile1.c\n>>   Auto-merging otherfile2.c\n>>   Auto-merging otherfile3.c\n>>   Resolved 'foo.c' using previous resolution.\n>>   Resolved 'bar.c' using previous resolution.\n>>   Automatic merge failed; fix conflicts and then commit the result.\n>>   $ git mergetool\n>>   No files need merging\n>>\n>> So rerere has remembered the bad resolution of foo.c.  But even if I\n>> run 'git rerere clear' and repeat the above sequence I get the same\n>> result.\n>\n> I think you actually want \"rerere forget\". Like:\n>\n>  $ git reset --hard HEAD^\n>  $ git merge topic\n>  $ git rerere forget foo.c\n>\n> Although it is slightly more complicated if you have set\n> rerere.autoupdate, since it will have cleared the index of any notion\n> that the path was conflicted. In that case you can then follow the\n> \"rerere forget\" with:\n>\n>  $ git reset --hard\n>  $ git merge topic\n>\n> to retry again.\n>\n> But it doesn't look like you have autoupdate on, from the output above\n> (it would say \"Staged 'foo.c'\" instead of \"Resolved 'foo.c\", I believe).\n>\n>> I seem to remember something like this coming up before.\n>> Wasn't there an option added to checkout to allow us to recreate the\n>> pre-merge state?\n>>\n>>   $ git checkout --merge foo.c\n>>   $ git mergetool\n>>   No files need merging\n>\n> If you have rerere.autoupdate on, then it will have updated the index,\n> and the path will not appear unmerged. You can use the trick above to\n> get past it.\n>\n> If you aren't using rerere.autoupdate (and haven't updated the index\n> yourself), you shouldn't even need the \"git checkout --merge\" line. It\n> just updates the working tree with the conflicted content, but mergetool\n> will operate directly on the original versions contained in the index,\n> anyway.\n>\n>>   $ git status\n>>   # On branch master\n>>   # Your branch is behind 'origin/master' by 1 commit, and can be\n>> fast-forwarded.\n>>   #\n>>   # Changes to be committed:\n>>   ....\n>>   # Unmerged paths:\n>>   #   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n>>   #\n>>   #   both modified:      foo.c\n>>   #\n>>\n>> foo.c now does have conflict markers in it so I think it's crying out\n>> to be re-merged I just can't convince mergetool to do it. Am I doing\n>> something wrong?\n>\n> Hmm. That does seem like \"git checkout --merge\" did the right thing, but\n> that \"mergetool\" is wrong for not accepting it (it _should_ just be\n> looking at what's in the index to find unmerged paths).\n>\n> Ahh. It is probably the fault of bb0a484 (mergetool: Skip autoresolved\n> paths, 2010-08-17), which checks with rerere to avoid resolved paths. So\n> I think:\n>\n>  $ git rerere forget foo.c\n>  $ git mergetool\n>\n> would do what you want.\n>\n> -Peff\n>\n\nThanks that sounds like what I want. I've also been a bit lazy and\ndidn't run 'make install-doc' when I upgraded to 1.7.5.4 so my system\nman pages (1.7.0.4) don't mention rerere forget but it's there in\nrerere -h.\n\nPerhaps checkout --merge <path> should automagically tell rerere to\nforget about the path?\n"},{"id":"171008","messageId":"7vaacphale.fsf@alter.siamese.dyndns.org","threadId":"27775","inReplyTo":"CAFOYHZCFetkokgtn4z0O3nPTEy6GCTEcN0Pzc8ce-joqMzZM1Q@mail.gmail.com","subject":"Re: Redoing a merge for a particular file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-08T00:36:45Z","receivedAt":"2011-07-08T00:36:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n>   $ git merge topic\n>   Auto-merging foo.c\n>   CONFLICT (content): Merge conflict in foo.c\n>   Auto-merging bar.c\n>   CONFLICT (content): bar.c\n>   Auto-merging otherfile1.c\n>   Auto-merging otherfile2.c\n>   Auto-merging otherfile3.c\n>   Resolved 'foo.c' using previous resolution.\n>   Resolved 'bar.c' using previous resolution.\n>   Automatic merge failed; fix conflicts and then commit the result.\n>   $ git mergetool\n>   No files need merging\n>\n> So rerere has remembered the bad resolution of foo.c.\n\nI would do this:\n\n $ git rerere forget foo.c\n $ git checkout -m foo.c\n\nthen fix it up and\n\n $ git add foo.c\n $ git commit\n"},{"id":"171009","messageId":"7v62ndhajm.fsf@alter.siamese.dyndns.org","threadId":"27775","inReplyTo":"CAFOYHZBBtqK2VtZ-Bq3uMAhGD4esSz7JDJn_4xaKb4y8wt9LJA@mail.gmail.com","subject":"Re: Redoing a merge for a particular file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-08T00:37:49Z","receivedAt":"2011-07-08T00:37:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> Perhaps checkout --merge <path> should automagically tell rerere to\n> forget about the path?\n\nNOOOOOOOO. Please don't.\n"}]}