Michael J Gruber <git@drmicha.warpmail.net> writes:

quoted text
> Junio C Hamano venit, vidit, dixit 15.06.2010 18:37:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>> +'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?

The latter.  You can have more than one rerere database entries for the
same path (i.e. merge conflict resolutions for unrelated branches, each of
which changes unrelated things that happen to be in the same path).  The
entries in the rerere database are "when we see a conflict of this shape
(anywhere), the user wants to resolve it this way", indexed by the shape
of the conflict.  There is no "path" recorded in the database.

When "rerere forget" is run, it needs to be told which entry to forget,
and this is done by regenerating the conflict you just had (and possibly
have already resolved, if you are using recent enough git that knows
"resolve undo") using the information in the index, and <pathspec> is used
to limit this set (i.e. when you have more than one path conflicted in the
current merge).

quoted text
> 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?

Once you write the result of a merge out to a tree, the tree does not even
know if there was a conflict.  It does not know how you arrived to that
state in general.  You simply don't have enough information after reading
a tree into your index in order to "amend" it.  When reading a tree that
belongs to a merge commit into the index, we _could_ try to regenerate the
conflicted state and immediately resolve them to the tree's state but I
don't think it is worth the cost and complexity.  Besides, at that point
you do not even know what merge strategy (and which version of that
strategy) was originally used.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html