Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)

On 5/4/07, Johan Herland [off-list ref] wrote:

1. "Reverts": Mark a commit as reverting another commit. This could be
used by git-log to cancel out pairs of commits, resulting in a cleaner
view of history. It can help blame/annotate. There are probably other
tools that can benefit from this information also.

2. "Cherry-Pick": When cherry-picking a commit onto another branch, you
should be able to tell git which commit you are cherry-picking
(git-cherry-pick would of course do this automatically). This could
enable git to make smarter decisions when merging the two branches: If
the cherry-picked commit would cause a conflict with the original
commit, git can either skip it (since it knows that one version of this
patch is already present), or it can at least present the conflict to
the user with some more context than what is available today. Not to
mention how this information could be used by blame/annotate.

These are completely useless after the first "git gc --prune" or "git clone"
unless these tools taught to preserve the reverted or cherry-picked commits
(and all their history). And if you are about to teach them that, please notice
that as for now cloning and repacking does not even look at the
objects contents.
You'll absolutely kill their performance.