Branching strategy for git

[John Ralls]

On Mar 27, 2014, at 8:14 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On Thursday 27 March 2014 07:45:14 John Ralls wrote:
> > On Mar 27, 2014, at 1:47 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> > > On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> > > > On the matter of feature branches, I'm tempted to create two
> > > > public
> > > > ones, 'boost' and 'mvc' to provide a long-running context to those
> > > > changes and to encourage others to join the fun.  A third,
> > > > 'core-sql', would come after the engine has been cleaned up enough
> > > > for it to be practical. What do you think?
> > > 
> > > How much overlap is there in the 'boost' and 'mvc' work ? I'm just
> > > trying to estimate if they can be done on separate branches. But
> > > perhaps you already have a vision on that.
> > 
> > The Boost changes will touch everything because it's going to include
> > a lot of API shrinkage, like getting rid of most of the different
> > ways we say "time", and changing object calling conventions from
> > gnc_footype_bar(foo, baz) to foo->bar(baz).
> > 
> > MVC is more of a refactoring exercise, pulling everything that doesn't
> > immediately draw on the screen or get from the user out of the GUI
> > code into a controller layer, the objective being to make switching
> > UIs a more-or-less mechanical exercise.
> > 
> > They'll need to be frequently merged back-and-forth with master to
> > keep everything in sync. Do you think that will add too much extra
> > work and that we should just do everything in master as we have been?
> > 
> The branching strategy in git will be an experiment for me as I never worked in an environment before that used git and a true git workflow. So my opinion on this is mostly academic.
>  
> Having said that would definitely do such big refactorings on one or more separate feature branches.
>  
> I'm interested in getting more familiar with how git can be leveraged to a maximum in the development cycle. If people with lots of git experience suggest that branches are the way to do this I assume they have good reason to. (Better would be of course if we fully understood these reasons ourselves but I don't feel like learning by trial and error in this case.)
>  
> For one should the proposed refactorings turn out to take much more time than anticipated and we would want to ship a 2.8 with other smaller features that would be easier if the refactorings are on their own branches.
>  
> That assumes of course that only atomic change sets from the feature branches can be merged into master. Not half finished features.

Yeah, unfortunately Gnome still pretty much follows the SVN model, so I don't have much experience with this either.

I don't see either of these as all-or-nothing change sets, and I envision frequently merging both branches back into master. Pieces of them are: It would be dumb to have part of  GnuCash using the current glib-based GncDate and part using boost::calendar::gregorian. It would be asking for serious trouble to have part using GncNumeric and part using boost::rational. But I don't see any reason, aside from timing, not to have a release with one and not the other.

I read through a bunch of web articles about long-running topic branches, and most of them were negative; on the other hand, most don't like Driessen's git-flow while always remarking on its popularity.

We haven't had any significant problems with private branches in the last year, so let's just keep doing it that way until we have a problem or a situation where more than one person wants to work on the same thing.

Regards,
John Ralls