From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Wed, 16 Jun 2010 07:42:24 GMT
Subject: Re: [PATCH] rerere.txt: Document forget subcommand
Message-ID: <4C188060.5000903@drmicha.warpmail.net>
In-Reply-To: <7vr5k86ylg.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 15.06.2010 18:37:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
>> introduced the forget subcommand for rerere.
>> ...
>> diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
>> index acc220a..a7370d3 100644
>> --- a/Documentation/git-rerere.txt
>> +++ b/Documentation/git-rerere.txt
>> @@ -40,6 +40,10 @@ This resets the metadata used by rerere if a merge resolution is to be
>>  aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
>>  will automatically invoke this command.
>>  
>> +'forget' <pathspec>::
>> +
>> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
>> +
> 
> This description is not _incorrect_ per-se, but it does not convey one
> important aspect of the subcommand; unlike "clear" and "gc", "forget" only
> works in the context of the _current_ conflict resolution, just like
> "diff" and "status".

Does "current context" mean

- any recorded resolutions for the hunks which are currently recorded as
in in conflict

or

- the resolution which has (just) been recorded for the current conflict?

I'm completely agnostic of the underlying implementation of rerere (as
demonstrated by my questions probably...).

> Perhaps s/for <pathspec>/for the current conflict in <pathspec>/ would be
> a sufficient improvement?

I guess that would mean 2 above?

In any case, rerere forget is not a solution for the original "amend
merge commit and forget previous resolution" question, I guess (I just
happened to note it's undocumented). One would have to redo the merge to
get the conflict info into the index, right?

Michael