Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Junio C Hamano venit, vidit, dixit 15.06.2010 18:37: >> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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). > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html