LWN: Comments on "How patches get into the mainline"

Fast-forward merges

jwboyer — Fri, 13 Feb 2009 02:22:19 +0000

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

Fast-forward merges

junkio — Fri, 13 Feb 2009 01:55:48 +0000

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.

How patches get into the mainline

rgilton — Fri, 13 Feb 2009 00:11:00 +0000

Can you use the "Signed-off-by" tag to do a similar thing?

Fast-forward merges

corbet — Thu, 12 Feb 2009 15:09:46 +0000

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.

How patches get into the mainline

jwboyer — Thu, 12 Feb 2009 12:56:42 +0000

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.

cherry picking

nevets — Thu, 12 Feb 2009 02:13:09 +0000

One thing the article leaves out, is the number of patches that are cherry picked. I have a git tree that I use to send Ingo my patches. I usually base it off of his tip/master branch, and he must cherry pick them into the appropriate branches.

Even if I base off one of his branches and he pulls it into that branch. After the merge window closes, Ingo cherry picks the patches that will go to Linus. Only the changes that fix bugs are usually in that category. If I send Ingo a series of changes that also contain a couple of bug fixes. He may need to cherry pick those bug fixes to send to Linus.

All of the cherry picks lose the origin of the repo they came from.