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."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
