Re: [PATCH/RFC 0/3] git rerere unresolve file

Quoting Johannes Sixt [off-list ref]

On Sonntag, 22. November 2009, Junio C Hamano wrote:
[snip]

quoted

 * Then the user tells rerere that "this is the corrected resolution",
   perhaps

   $ git rerere update Documentation/git-commit.txt

   This will

   - Internally recompute the original conflicted state, i.e. run
     "checkout --conflict=merge Documentation/git-commit.txt" in-core;

   - feed it to rerere.c::handle_file() to learn the conflict hash;

   - read the user's updated resolution from the work tree, and update
     "postimage" with it.

...

The "forget" subcommand may be useful, but the real implementation should
be the first half of the "update", iow, recreate conflict in-core in order
to compute the conflict hash, and drop existing "postimage", without
replacing it from the work tree.  We should leave it up to the user using
"checkout --conflict" to reproduce the conflict in the work tree.

Thank you for your elaborate feedback and the guidelines about how to move 
forward.

I actually think that 'forget' should be the primary subcommand. Because after 
the postimage was purged, the next implicit or explicit 'git rerere' will 
record the resolution anyway. I'll see what I can do.

-- Hannes

I think 'forget' should be the primary interface to this new feature too. If I mistakenly recorded an incorrect merge in the past and I'm trying to do a better job this time, I wouldn't be confident enough to be able to say 'update' to mark the attempt I made this time, and it may take more than one attempts for me to reach a good result. Running 'forget' once will let me retry until I run 'rerere' again.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/