| |||||||||||||
How patches get into the mainlineHow patches get into the mainlinePosted Feb 12, 2009 12:56 UTC (Thu) by jwboyer (guest, #23296)Parent article: How patches get into the mainline
Your charting (or git more likely) doesn't seem to take into account fast forward merges. This is evident by the lack of the sub-arch trees for PowerPC. There are at least 3 trees that commits flow into before they go into benh's tree, and none of those are present in your chart. Those sub-arch maintainers try to make it as easy as possible for benh to merge things, so the pull requests are often simple fast forwards on top of his tree. I doubt you'd get a merge commit there.
Just something I found interesting.
(Log in to post comments)
Fast-forward merges Posted Feb 12, 2009 15:09 UTC (Thu) by corbet (editor, #1) [Link] In fact, that's why the article expends a paragraph on the problem of fast-forward merges. The information is simply lost in that case, and there's really not much that can be done about it.
Fast-forward merges Posted Feb 13, 2009 1:55 UTC (Fri) by junkio (subscriber, #5743) [Link]
True, but you can probably notice the committer information is different between the parent commit and the child commit. Linus publishes his tip, David S Miller builds on top and gives Linus a pull request, and Linus fast-forwards. Then these commits brought in to Linus's repository via Dave's repository will record Dave as the committer, not Linus.
Fast-forward merges Posted Feb 13, 2009 2:22 UTC (Fri) by jwboyer (guest, #23296) [Link]
Ugh. Apparently my brain skipped that paragraph when reading the article.
I blame it on the fact that a very pretty graph is placed rather close and it's shininess distracted my brain.
Sorry for the superfluous comment (twice now!).
|
|||||||||||||