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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sep 11, 2008, 16:23 UTC
Message-ID: <alpine.LFD.1.10.0809110910430.3384@nehalem.linux-foundation.org>
In-Reply-To: <48C940C8.6040407@gnu.org>

On Thu, 11 Sep 2008, Paolo Bonzini wrote:

Show 5 quoted lines

> 
> Yes, but you should not have used Stephen's proposed new option to git
> cherry-pick, just like you shouldn't have used the existing -x option.
> "-x" would not have created a dangling reference, but it would have
> created a puzzling commit message.

But my point is, _none_ of what Stephen proposes has _any_ advantage over the already existing functionality.

IOW, absolutely *everything* is actually done better with existing data structures, and then just adding tools to perhaps follow those SHA1's in the commit message.

The whole "origin" field doesn't have any semantics that make sense for core git. It's basically ignored by all normal git operations, and the _only_ things that people seem to point out as being features are things that can - and obviously in my opinion should - be done by much higher levels.

For example, the claim was that it's hard to follow the chain of cherry-picks. That's not _true_. Use gitweb and gitk, and you can already see them. Sure, you need to use "-x", BUT YOU'D HAVE TO USE THAT WITH Steven's MODEL TOO!

Exactly because it would be a frigging _disaster_ if that "origin" field was done by default.

And the only thing that "origin" does is:

 - hide the information

 - make it easier to make mistakes (either enable the feature by default, 
   or not notice that you didn't enable it when you wanted to)

 - add a requirement for a backwards-incompatible field that is just 
   guaranteed to confuse any old git binaries.

 - make it _harder_ to do things like send revert/cherry-pick information 
   by email.

See? There are only downsides.

Look at the kernel -stable trees. They explicitly add that cherry-pick information, and can add *more*. For example, they go look at

	http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=commit;h=cb09de4542ad75cc3b66d0cf1a86217bf5633416

and then go to its parent commit (just click on the parent SHA). And notice how the stable kernel tree commits talk about where they were back-ported from, or _why_ they aren't back-ports at all!

IOW, there are really two main cases:

 - the common case for cherry-picking: you do not want any origin 
   information, because it's irrelevant, pointless, and *wrong*.

 - you _do_ want origin information, but you actually want to _explain_ 
   explicitly why it's not irrelevant, pointless, or wrong.

And yes, the latter case is about a lot more than "this was cherry-picked". It's about "this fixes that other commit we did", or it's about "this was anti-cherry-picked - ie reverted". They are all "origins" for the commit in the sense that they are relevant to the commit, but they all need some explanation of what _kind_ of origins they are.

			Linus