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.
- 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.
- 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.
- Sharing .git/rr-cache. It's quite a PITA to share the .git/rr-cache
amongst -tip maintainers right now. It seems to have dependencies on
the index file, so if we want to share the conflict resolution data,
we have to copy our index file (which is dangerous anyway and assumes
very similar repositories).
It would be much nicer if we could share conflict resolutions with
each other - and with others as well. For example linux-next could
re-use our conflict resolution data as well - often Stephen Rothwell
has to re-do the same conflict resolution as well, creating
duplicated work.
( Also, it's a GPL nitpicky issue: the conflict resolution database
can be argued to be part of "source code" and as such it should be
shared with everyone who asks. With trivial merges the data is
probably not copyrightable hence probably falls outside the scope
of the GPL, but with a complex topic tree like -tip with dozens of
conflict resolutions, the boundary is perhaps more blurred. )
Ingo
--
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
