Re: [PATCH/RFC 0/3] git rerere unresolve file
Quoting Johannes Sixt <j6t@kdbg.org>
Show 33 quoted lines
> On Sonntag, 22. November 2009, Junio C Hamano wrote:
> [snip]
>> * 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/
Nanako Shiraishi <nanako3@lavabit.com>