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

[Geert Janssens]

On 01-02-13 16:45, Derek Atkins wrote:
> Geert Janssens <janssens-geert at telenet.be> writes:
>
>>> One more note on that: E may very well end up looking nothing like D
>>> because B-C may have been enough of a change that a different
>>> approach is required, but it's still necessary for it to be a
>>> multi-parent commit.
>>>
>> Absolutely. The extreme case being if commit D is not even wanted on
>> the trunk branch (like a product version number increase for
>> example). It would still have to be merged. You could choose to do it
>> on commit D, resulting in an empty commit with two parents, or you can
>> wait for commit H, and make sure the changes from commit D are
>> reverted during the later merge.
> This is going to be important as we make new stable releases.  We're not
> going to want the e.g. 2.6.0 -> 2.6.1 -> 2.6.2 commits to merge back
> into trunk.  So when the branches are merged after stable releases these
> commits will need to be omitted (or reverted) during the merge.
>
> -derek
>
Yes, that is true. If the person doing the merge is paying attention, he 
could fix the merge before committing it to omit the version number 
change. Otherwise a reversing commit on the development branch can fix 
it as well.

I don't know if there is a good in-scm solution for this. One way to 
avoid this it branching from stable right before releasing into a 
release-only branch or even a unique branch per release. Only that 
branch could hold the version number update. Since it's on a separate 
branch this release number update won't get merged back to trunk.

This actually looks a lot like my first proposal of having a bugfix 
branch from which commits get merged into both stable and development. 
The names are swapped around a bit and the unspoken premise is that the 
release branch only has an absolute minimum of unique commits strictly 
related to releasing (like version updates). Other than that it only 
takes merges from the stable branch. That would make these merges from 
stable to release trivial in all cases and would still allow you to omit 
certain bugfixes from release for any reason (make an empty merge to the 
release branch for that bugfix).

With all that has been said so far, I slowly come to like the 
multi-branch approach:
- one branch for future development (features, refactoring, anything to 
complex for a stable release)
- there can be subbranches for separate features or refactoring efforts 
that get merged into the main development branch when they are 
considered ready
- one branch for stable development (bugfixes, translation updates). 
This branch gets merged into development regularly to get all bugfixes 
into the future development as well
- one release branch. The only direct commits here are those purely 
related to releasing, like updating the version number. Other than that 
it receives bugfixes and translation updates merged in from the stable 
branch.

This setup has room for a similar process we had with BP/AUDIT. If there 
is a dedicated gatekeeper, his job would be to evaluate all commits on 
the stable branch and merge them into the release branch if they are 
considered ok for release. Commits that are not ok, can be skipped by 
clever merging (1). If there's no dedicated gatekeeper, every committer 
is responsible for merging his changes into the release branch or making 
sure they get skipped. In both cases every committer is responsible for 
getting his bugfixes merged into the future development tree.

At any time the merge state of the stable branch shows what bugfix 
history still needs merging.

I'm starting to see a pattern here in git: whatever your problem: fix it 
with a branch ;)

Geert

(1) How to skip using merge:
- make sure the parent commit of the one you wish to skip is merged in 
your target branch
- then use merge -s ours <commit> to merge in the commit you wish to skip
The "ours" merge strategy will discard the changes in the branch you're 
merging in. For that reason it's important that any older commit you 
want to have merged from that branch is effectively merged before 
running the skipping merge.