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

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

Linus Torvalds wrote:
>On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>> But then how would someone who clones the repository get at the information?

>You just said it wouldn't get there with fetches.

True and still valid.

>If clone acts differently from a "full" fetch, something is really really 
>wrong.

It does not act differently.

Let me elaborate:

- The origin field is part of the commit (and only present if
  *consciously* added by the committer), and therefore is transmitted
  along with the rest of a commit upon a fetch.

- The commits being referred to by the origin field are *not*
  transmitted upon a fetch.

- Given a repository with 4 long lived published branches called A, B, C and D
  and a backport from development branch D cherry-picked -o into branch A
  which creates an origin field pointing back to (D^,D^^)

- Now you fetch just branch A from this repository.  This will not cause
  branch D to be pulled in as well.

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

>> The information is essential to understand backports between the various
>> stable branches.

>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?
-- 
Sincerely,
           Stephen R. van den Berg.

"Am I paying for this abuse or is it extra?"