Ingo Molnar <mingo@elte.hu> writes:

quoted text
> We are running a rather complex Git tree with heavy use of git-rerere 
> (the -tip kernel tree, with more than 80 topic branches). git-rerere is 
> really nice in that it caches conflict resolutions, but there are a few 
> areas where it would be nice to have improvements:
>
>  - Fixing resolutions: currently, when i do an incorrect conflict
>    resolution, and fix it on the next run, git-rerere does not pick up
>    the new resolution but uses the old (buggy) one on the next run. To
>    fix it up i have to find the right entries in .git/rr-cache/* and
>    manually erase them. Would be nice to have "git-rerere gc <pathspec>"
>    to flush out a single bad resolution.

I agree this is a real issue (I sometimes know that the resolution is iffy
and say "rerere clear" to choose not to record it, but that is working
around the issue with a perfect foresight and is not a solution).

I think (and I think you would agree) "gc" is not the right word but
rather you would want to more actively discard the wrong one.

I agree that it is the right UI to do this to specify paths right after
you found that a bad resolution that was recorded previously was used by
rerere (I think that is what you are suggesting).  Upon such a request, we
should undo the bad resolution and bring the working tree copy to the
original conflicted state, and clear the bad rerere entry.

quoted text
>  - File deletion: would be nice if git-rerere picked up git-rm
>    resolutions. We hit this every now and then and right now i know 
>    which ones need an extra git-rm pass.

I originally did not have need for anything other than three-way conflict
resolving to a result.  I do not know how safe reapplying a removal to
different context, though.

quoted text
>  - Automation: would be nice to have a git-rerere modus operandi where
>    it would auto-commit things if and only if all conflicting files were 
>    resolved.

I am not sure how safe this is.  rerere as originally designed does not
even update the index with merge results so that the application of
earlier resolution can be manually inspected, and this is exactly because
I consider a blind textual reapplication of previous resolution always
iffy, even though I invented the whole mechanism.
--
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