How to handle multiple long-term branches (was Re: Notification mails for git repos)

Geert Janssens janssens-geert at
Thu Jan 31 13:48:29 EST 2013

On 31-01-13 19:04, John Ralls wrote:
> On Jan 31, 2013, at 9:06 AM, Geert Janssens <janssens-geert at> wrote:
>> On 31-01-13 17:15, John Ralls wrote:
>>> On Jan 31, 2013, at 7:04 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>>>> Geert Janssens <janssens-geert at> writes:
>>>> [snip]
>>>>> Daggy fixing is probably not the only useful scheme though. I could
>>>>> also imagine something like this to work:
>>>>> - all bugfixes and only bugfixes happen on the 2.4 branch
>>>>> - the 2.4 branch regularly gets merged into the development branch, so
>>>>> all bugfixes also will end up in future releases
>>>>> This concept is no longer back-porting, but
>>>>> forward-porting. Advantage: all bugfixes eventually end up in the
>>>>> active trees and git branches show the history, no need for BP->AUDIT
>>>>> Note that neither daggy fixing nor forward porting are possible as
>>>>> long as we're tied to svn. So this discussion is on future process,
>>>>> not practical next steps yet.
>>>> Techncally we could do the "all bugfixes go into release; frequently
>>>> merge release back into trunk" method.  The downside is that larger
>>>> "fixes" dont get tested as much before going into the release.
>>> I think that you guys have a misunderstanding about how merging works.
>> Perhaps I do. That's why I'm discussing this topic here :)
>>>   Try merging 2.4 back into trunk.
>>> When I did just now, 4 files merged successfully, the rest have conflicts. One might be able to do better by playing with the merge options. I'm not going to spend the time.
>> I believe this is in large part  because the common ancestor between 2.4 and trunk is already too far down history. I explicitly said regularly merging into the development branch.
> No, you're looking at it backwards. The conflicts arise from changes to trunk, not stable.
> We don't develop *anything* in the stable branch -- at least, we're not supposed to. Trunk changes, 2.4 mostly doesn't, and all of the changes in 2.4 are supposed to have been made in trunk first, so if trunk hasn't diverged much from stable, then a merge from stable into trunk should be a no-op.
That's the main premise I was challenging. Suppose we *do* develop on 
2.4, but bugfixes only or if you will more generally, only that stuff we 
actually want to end up in the next 2.4.x release (like translations as 
well for example). It would obviously be important to clearly define 
what's welcome on a stable branch and what isn't.

> The problem of course is that trunk *does* diverge. That's the whole point of having a stable branch. As trunk diverges, the code required to implement a bug fix becomes different between the two branches. The merge conflicts arise from those differences.
Yes, that's clear. And it would be the same if bugfixes (those we *want* 
in the next release) are done on the stable branch and then merged 
forward into development. I'm *not* focussing on the merge conflicts. 
They will be there in both cases. I'm focussing on traceability of the 
commits that are supposed to go on both branches. Since generally 
speaking all bugfixes we want on the stable branch should also be in 
development but not the other way around, my proposal makes it easier to 
trace: just look at the last merge from stable to development. Any more 
recent commit on stable is not merged into development yet.
> Now we *could* reduce that divergence by adopting a scheduled release process like Gnome has done. Then trunk would never be more than 6 months different from the current stable branch. We could go even further and adopt "continuous integration", though that's always seemed to me to be an anti-user approach (Gnome's users have been noisily unhappy), and both seen risky  given our poor test coverage.
Agreed these are not really good options with our current code base and 
development team size.
>> Our current process (using the BP and AUDIT markers) has the same weaknesses IMO. There is no clear indication in the commit history of which commits were backported. We have BP/AUDIT as a visual reminder that backports should happen, but no easy way to check in retrospect if they actually happened.
> Go reread the Wiki article on BP/AUDIT [1]:
> "Developers should request changesets get audited and approved before they are pulled into the release branch."
> The intent was that backports should get a code review from another developer before being committed to stable. Since we don't actually do that, perhaps the automated email is superfluous anyway.
Indeed, I implicitly worked from the actual current situation, not how 
it was originally intended and written in the wiki. I think an automated 
mail in general is still useful, but I'm questioning the BP/AUDIT extra 
>   We could instead require a bug for backports and include the bug number in both commits, and both commits could be referenced in the bug before closing it. The commit note in stable could also note the source commit from trunk. When one finds a bug on one's own it's pretty easy to write a bug to satisfy that requirement, and ISTR someone mentioning a git-Bugzilla utility of some sort in the last couple of weeks.
That could probably work as well. I suppose the bug should only be 
marked as fixed after is available on both branches, regardless of the 
mechanism we'd use to get them there. But still: can we enforce the bug 
to remain open until that is the case ? What if someone closes a bug too 
soon ? How will we know that commit still has to be copied one way or 
another to the other branch ? Again I think having it visually in the 
commit history looks stronger to me.

Just to be honest and complete, I will add myself what I perceive as a 
weakness in my model:
How do we know upfront which fixes we want on the release and which ones 
we we don't ? Sometimes it's only clear *after* the bug has been fixed 
how complex the solution has become and whether it could still be 
considered for backporting.

For my model, I'd rely on separate working branches and git's 
flexibility of rebasing branches to deal with this:
- for a bugfix, create a working branch from stable and fix the bug on 
that branch.
- If it turns out to be more complicated than originally intended, 
either you decide it's not for stable (potentially after peer review and 
discussion) or it still is.
- In the first case, rebase the branch to development (potentially 
dealing with merge conflicts due to diverged trees - a clear drawback).
- In the latter case, merge the working branch in stable, to be merged 
back into development later on.

This situation should be infrequent in my opinion though. For most bugs 
a fairly good estimate of the impact can be made before writing the 
first line of code and based on that the appropriate base branch can 
already be chosen.


More information about the gnucash-devel mailing list