Op 16-3-2012 17:01, Junio C Hamano schreef:
Vincent van Ravesteijn<vfr@xxxxxxx> writes:
Op 12-3-2012 21:01, Junio C Hamano schreef:
...
I haven't find it necessary in practice, as the re-fix for me
typically would go like this:
$ git merge other-branch
... rerere kicks in; eyeball the results
... ah, my earlier resolution is no longer correct
$ edit $the_path
... test the result of manual edit in the context of the merged whole
... and be satisified
$ git rerere forget $the_path
$ git add $the_path
$ git commit
... rerere records the updated resolution
This doesn't really work for me:
$ git merge other-branch
Auto-merging<path>
CONFLICT (content): Merge conflicts in<path>
Resolved '<path>' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.
$ git rerere status
$ git rerere forget<path>
error: no remembered resolution for<path>
$ edit<path>
$ git commit -a -m "fix"
... no sign of rerere doing something.
Why is this different from what you describe above, and how can I
modify the recorded resolution ?
Do you have rerere.autoupdate set by any chance? If so, don't. At least
when you are trying to purge the broken rerere entry.
No, I turned rerere.autoupdate off. Proven in the above by the line
"Resolved... " instead of "Staged...".
Vincent
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html