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

From: Alex Riesen <raa.lkml@gmail.com>
Date: May 4, 2007, 22:11 UTC
Message-ID: <20070504221152.GF4033@steel.home>
In-Reply-To: <200705041353.17992.johan@herland.net>

Johan Herland, Fri, May 04, 2007 13:53:10 +0200:

Show 5 quoted lines

> 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.

So it becomes useless after rebase

> 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.

In which case, just put it in the message part of commit (in fact, it was there for some time. And was mostly useless, and got dropped).

And how exactly do you think the tools _can_ use this hint? Especially merge, which should be absolutely certain about what inputs and hints gets. And what use is it for blame? How do you prioritze the hint? Is it more important than the history (which describes each and every line), or less? If the hint is more important, than how (and how often) do you tell the user that the hint was not found (because the commit is long pruned) and the tool switched back to looking into history.

It's useless.