Ingo Molnar <mingo@xxxxxxx> writes: > 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. > - 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. > - 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
