Hey, cdub sent on these interesting links:
http://lwn.net/Articles/328438/ https://lkml.org/lkml/2012/3/22/489 tl;dr on those is that you're likely to be flamed as a f*cking moron by Linus unless you manage to understand every little nuance about how he thinks git should be used :-) It's really quite interesting to dig into the way Linus does things ... Some random observations: - There's a transition from work being in a "git rebase" phase to a phase where it should never rebase again. Allegedly, this transition happens when you publish a git tree with the work. It seems to me, though, that the transition is really when a subsystem maintainer merges your tree into a tree that is known to be their non-rebasing "release" tree that gets sent to linus regularly. - What can also happen is that a maintainer picks up a patch, applies it to their rebasing "next" tree, adds their Signed-off-by and may happily rebase it until they merge it into their "release" tree. - The Signed-off-by thing is interesting - the first Signed-off-by in a commit should match the Author: field and the last should match the Committer: field. Once the commit transitions from the "git rebase" phase, no more Signed-off-bys are added. There may be multiple Signed-off-bys where a patch has passed through several peoples' hands before transitioning out of the "git rebase" phase. - There's a strange emphasis on sharing work-in-progress as patches rather than via git. It's not hard-and-fast, but there's an element of "while the work still may re-base, it should be shared mostly as patches" The root of this is the whole "never rebase a public git tree" thing. If you want a patch merged into the kernel, the usual way is for the maintainer to apply your patch from the mailing list rather than merge a git tree from you. I find this strange - there's a big flap about "NEVER destroy other people's history", yet there's a preference for folks to submit changes in a way that destroys the history of what exact parent commit their work was based on? - Kernel maintainers mostly assume the responsibility of resolving merge conflicts. Certainly they do so after the transition out of the "git rebase" phase, but often before that too. How does this compare to our process? - All our changes come in as git commits, not patches - Typically, only the author of the patch ever re-bases it - Our merge commits never resolve any conflicts. If a merge attempt results in conflicts, we ask the author to rebase - The transition out of "git rebase" phase happens when the commit is merged into master. There's no concept of a commit transitioning out of that phase earlier - If we used Signed-off-by with our current process, there would only be multiple Signed-off-bys where there the work has multiple authors - Our history is far from "clean history", it's pretty disgusting really. The ratio of interesting commits to merge commits is roughly 3:2, which is pretty cluttered. With the kernel, it's more like 15:1 Anyway, food for thought. Cheers, Mark. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
