openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

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.