Branching strategy for git

John Ralls jralls at
Thu Mar 27 10:45:14 EDT 2014

On Mar 27, 2014, at 1:47 AM, Geert Janssens <janssens-geert at> wrote:

> On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> > On Mar 25, 2014, at 8:15 AM, Geert Janssens <janssens-geert at> wrote:
> > > If no one beats me to it I'll try to adapt the git wiki page with
> > > this info in the coming days.
> > OK. The main change seems to me to be that instead of making a '2.6'
> > branch next week I'll be making a 'maint' branch.
> > 
> > Have you experimented at all with what the upstream looks like if you
> > merge a private branch instead of rebasing it and then push the
> > result? I *think* the private branch's objects will get pushed
> > upstream, but the ref/heads entry won't, but I don't know that for
> > sure. If I'm right, then the other change in the wiki will be to
> > remove all of the stuff about rebasing instead of merging.
> > 
> Do you mean there should be no reference to rebasing anymore and to promote merging for everthing ?
> I think it still makes sense to rebase local branches right before making them public (which can be either by pushing to a public repository for those that have commit access or by creating a pull request).
> This somewhat limits the number of multi-parent commits in the public repository. Lots of those tend to make history harder to read or represent.


> > 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?

John Ralls

More information about the gnucash-devel mailing list