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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 11 Sep 2008, Paolo Bonzini wrote:
> 
> 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