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

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

Johannes Sixt [off-list ref] writes:

quoted

... But
there is no other way to remove an incorrect resolution short of purging
the whole rr-cache.

No, no no, no.  You do not have to.

Oh, yeah, I know. But even for people who know how to drive plumbing commands, 
this:

"ls -t1 .git/rr-cache/*/thisimage | head"
would be one way to manually find out which one it is.

does not count as "you can" in my book. ;) It assumes that there are at most a 
handful conflicted files. In my case, for example, I have to fix a merge 
where there are ~100 conflicted files.

 * 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