Linus Torvalds wrote:True and still valid. 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). 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| David Miller | Slow DOWN, please!!! |
| Peter Zijlstra | [PATCH 00/23] per device dirty throttling -v8 |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
