Re: Git workflow (was: Re: Planner xml field additions)

[Kurt Maute <kurt maute us>]

On Mon, 2009-04-20 at 18:40 +0200, Maurice van der Pot wrote:

> My own preference would be to keep the master branch in a state that can
> be released at any time. This means no file format changes and no
> partial features. Topic branches would be used for features that people
> need to collaborate on, for features that are so much work that
> in-between commits would be useful and for intrusive things that break
> compatibility.

Agreed.  Master branch must be clean and distribution ready.

> Now the thing that I'm not yet fully clear about is the merge strategy.
> Do we just merge all changes from a topic branch to master (the easy
> way) or do we want to clean stuff up before merging. Although it might
> seem that rebasing is perfect for the latter, it is highly discouraged
> to rebase branches that people have branched from. I sorta get the
> feeling that it's more trouble than it's worth, but I would like to
> find out how kernel developers deal with this. I would think that they
> collaborate on something before (and possibly after) making a clean
> branch to pull from for Linus.

I'm really not clear on the whole rebase concept yet, but this article
helps a bit:
http://www.gitready.com/intermediate/2009/01/31/intro-to-rebase.html

Not sure what you mean by rebasing branches that people have branched
from?  Is it something like this: ?

             o--o  <-- Branch Aa  
            /
        o--o--o  <--Branch A
       /
o--o--o--o    <-- Master

... and don't rebase Master from Aa?

> I realize that I'm a git newb, so any input or suggestions for a way of
> working are appreciated.

Me too!  I haven't read all of the Linus thread yet, and I don't really
understand how someone would destroy someone else's history (though I
agree with the concept).

Personally, I know I'm going to have to work with it a bit to fully
understand, but I like your idea of laying down some basic ground rules.


-- 
Kurt Maute <kurt maute us>