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

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

On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> 
> - However, if you explicitly pull D, the origin information from A to D can
>   be used.  People doing a generic clone get all four branches, and
>   therefore have all the important commits which normally could contain
>   origin links.  Note that even during a clone, commits pointed to by
>   origin links are not being transmitted (unless there already are other
>   reasons to send them along).

IOW, it's not actually transferring them and saving them, since a simple 
delete of the origin branch will basically make them unreachable.

Fine. At least it works the same way as fetch, then. But it's still a huge 
mistake, because it really does mean that it is technically no different 
at all to just mentioning the SHA1 in the commit message, the way we 
already do for backports.

The "origin" link has no _meaning_ for git, in other words.

> >No it's not. You can mention the backport explicitly in the commit 
> >message, and then you get hyperlinks in the graphical viewers. That works 
> >when people _want_ it to work, instead of in some hidden automatic manner 
> >that does entirely the wrong thing in all the common cases.
> 
> Could you spell out one of the common cases where it would do entirely
> the wrong thing?

It carries along information that is worthless and meaningless and hidden.

I refuse to touch such an obviously braindamaged design. It has no sane 
_semantics_. If it doesn't have semantics, it shouldn't exist, certainly 
not as some architected feature.

Nobody has shown any actual sane meaning for it. The only ones that have 
been mentioned have been for things like avoiding re-picking commits 
during a "git rebase", but (a) the patch SHA1 does that already for things 
that are truly identical an (b) since that information isn't reliable 
_anyway_, and since it's apparently a user choice, it's just "random".

I'm sorry, but "good design" is a hell of a lot more important than some 
made-up use case that isn't even reliable, and doesn't match any actual 
real problems that anybody can explain.

			Linus