Re: [RFC] origin link for cherry-pick and revert

[Theodore Tso <tytso@MIT.EDU>]

On Thu, Sep 11, 2008 at 02:31:48PM +0200, Stephen R. van den Berg wrote:
> 
> Well, the train of thought here goes as follows:
> 1. Sure, why not add a field (zero or more) at the bottom of the free-form
>    commit message reading like:
> 
>    Origin: bbb896d8e10f736bfda8f587c0009c358c9a8599 ee837244df2e2e4e9171f508f83f353730db9e53
> 
> 2. Add support to cherry-pick/revert to actually generate the field upon
>    demand.

"git cherry-pick -x" already generates the field you want.

> 
> 3. Then add support to prune/gc/fsck/blame/log --graph to take the field
>    into account.
> 

Um, why should "git fsck", or "git prune" or "git gc" need to
understand about this field?  What were you saying about unclean
semantics, again?  I thought you claimed that dangling origin links
were OK?  So why the heck should git fsck care?  And why shouldn't
gc/prune drop objects that are only referenced via the origin link.

> 4. Add support to filter-branch/rebase to renumber the field if necessary.

As we discussed earlier in some cases renumbering the field is not the
right thing to do, especially if the commit in question has already
been cherry-picked --- and you don't know that.  Again, this is why
prototyping it outside of the core git is so useful; it will show up
some of these fundamental flaws in the origin link proposal.

> Well, and after having done steps 1 to 5, the net result is that it
> works almost as if the field is present in the header, except that:
> - It is now at the end of the body in the commit message.
> - It takes more time to find and parse it.

A proof of concept, even if it isn't fully performant, is useful to
prove that an idea actually has merit --- which clearly not everyone
believes at this point.

I'll also note that having a ***local*** database to cache the origin
link is a great way of short-circuiting the performance difficulties.
If it works, then it will be a lot easier to convince people that
perhaps it should be done git-core, and by modifying core git functions.

Alternatively, if you think this is such a great idea, why don't you
grab a copy of the git repository, and start hacking the idea
yourself?  If you have running code, it tends to make the idea much
more concrete, and much easier to evaluate.  Or were you hoping to
convince other people to do all of this programming for you?

						- Ted