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

[Johan Herland <johan@herland.net>]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

On Friday 04 May 2007, Alex Riesen wrote:
> 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.

Of course I don't want "git gc --prune" or "git clone" to follow these links, 
or know anything about them at all.

As for "Reverts", the commit pointed to should already be in your history, 
since you cannot revert something that hasn't already been applied at an 
earlier point in your history. In other words, the reverted commit will 
automatically be included in your "git gc --prune" or "git clone" regardless 
of the "Reverts" fields, since "Reverts" can only point to an ancestor.

As for "Cherry-Pick", it's a fairly weak relationship that shouldn't affect 
anything except to give a hint to merge, blame, and similar tools. 
If "Cherry-Pick" identifies an object not in your repo (because of "git 
gc --prune" or "git clone"), that is obviously equivalent to not having 
a "Cherry-Pick" field in the first place. "Cherry-Pick" is only useful when 
you have access to the original commit (pointed to by "Cherry-Pick"), but in 
that case I think it could be _really_ useful.


Have fun!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]