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

["Alex Riesen" <raa.lkml@gmail.com>]

On 5/4/07, Johan Herland <johan@herland.net> 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.