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

["Stephen R. van den Berg" <srb@cuci.nl>]

Linus Torvalds wrote:
>But my point is, _none_ of what Stephen proposes has _any_ advantage over 
>the already existing functionality.

I think you're missing some of the advantages because you don't have a
lot of experience with cherry-pick workflows between multiple permanent
branches.

>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 best way to explain the difference is probably by implementing the
free-form support, so I think I'll do that.

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

The existing cherry-pick -x option doesn't cut it, it helps for the
simple cases, yes, but there are cherry-pick situations where it just
adds to the confusion.

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

That never was the intention, and never will be happening.

>And the only thing that "origin" does is:

> - hide the information

Only if you want to hide it, you control if it does, this point is moot.

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

The same holds for -x, so this point is moot as well.

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

This is a problem, I admit, but maybe this can be solved in the future.
Then again, since use of the feature is a *very* conscious decision, anyone
using the feature can advise their users to use git version xxx at least.

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

Not necessarily, adding an Origin field in the patch sent by mail is
easy.  I don't see how it would be more difficult otherwise.  Please
explain.

>See? There are only downsides.

I think I just neutralised all but one of the mentioned downsides, and
the backward compatibility issue is at least mitigated.

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

And this is impossible when using the origin link?  The usage with an
origin link would be just as flexible, even more so.

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

Quite, and my proposal is not generating those anyway.

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

Yes, and that *extra* information can and should go into the free-form
commit message, alongside of the origin field inside the header (or
trailer), just edit the commit message before committing after a
cherry-pick -o.  What's your point?
-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."