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

On Friday 04 May 2007, Alex Riesen wrote:

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

quoted

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, [off-list ref]
www.herland.net