From: Stephen R. van den Berg Date: Wed, 10 Sep 2008 23:09:06 GMT Subject: Re: [RFC] origin link for cherry-pick and revert Message-ID: <20080910230906.GD22739@cuci.nl> In-Reply-To: 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?"