Branching strategy for git

[Geert Janssens]

On Thursday 27 March 2014 10:27:58 John Ralls wrote:
> 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.
> 
Agreed. That a very pragmatic approach to move forward.

Geert