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?"
--
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
