Jay Soffian [off-list ref] writes:
Let's say you initiate a merge:
$ git merge topic
And this merge results in conflicts in two files, foo and bar. You
resolve the conflicts in both files, but then decide you don't like
how you resolved bar.
How do you set the index and working-copy back to the state it was
immediately after doing the merge for bar, while leaving the merge
resolution alone for foo?
Before you "git add bar", you can say "git checkout --conflict=merge bar"
(or --conflict=diff3).
After "git add bar", you can't. Save what you have resolved so far in a
separate file (e.g. "cp foo foo.resolved"), reset to the previous state
and redo the merge.
Junio C Hamano [off-list ref] writes:
Jay Soffian [off-list ref] writes:
quoted
Let's say you initiate a merge:
$ git merge topic
And this merge results in conflicts in two files, foo and bar. You
resolve the conflicts in both files, but then decide you don't like
how you resolved bar.
How do you set the index and working-copy back to the state it was
immediately after doing the merge for bar, while leaving the merge
resolution alone for foo?
Before you "git add bar", you can say "git checkout --conflict=merge bar"
(or --conflict=diff3).
Or (if I understand manpage correctly) just "git checkout --conflict bar".
After "git add bar", you can't. Save what you have resolved so far in a
separate file (e.g. "cp foo foo.resolved"), reset to the previous state
and redo the merge.
Hmmm... isn't it what "git update-index --unresolve bar" is for?
--unresolve::
Restores the 'unmerged' or 'needs updating' state of a
file during a merge if it was cleared by accident.
Unless "git add foo" not only adds current contents of foo at stage 0,
but also removes higher stages from index...
--
Jakub Narebski
Poland
ShadeHawk on #git