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

[Geert Janssens]

On 31-01-13 18:26, John Ralls wrote:
> On Jan 31, 2013, at 8:52 AM, Yawar Amin <yawar.amin at gmail.com> wrote:
>
>> Hi John,
>>
>> On 2013-01-31, at 11:15, John Ralls <jralls at ceridwen.us> wrote:
>>
>>>> [...]
>>>>
>>> I think that you guys have a misunderstanding about how merging works. 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.
>>>
>>> Merging a commit doesn't just look at the files touched by that particular commit, it looks at every difference between the trees of the source commit and the target (i.e., the current branch).
>>>
>>> Cherry-pick exists for a reason.
>> I think we have to look at this from the other end: 2.4 is not merging cleanly into trunk precisely _because_ of all the cherry-picking/backporting that's been going on.
>>
>> If you create a new git branch, e.g. 2.6, from trunk, and don't allow any backported patches on it, I'd say you'd have a much better chance of a clean merge.
> If you create a new git branch from trunk and don't make any changes (remember, backports are the only allowed changes on a release branch), then of course it will merge cleanly: It won't have any changes, so the merge will be a no-op.
>
> Geert corrected me about when 2.4 was branched, so we can easily demonstrate this using 2.4.3:
> $ athena:/Users/john/gnucash> git merge 2.4.3
> Already up-to-date!
>
> Kinda misses the point about having a stable branch, though.
>
> Regards,
> John Ralls
>
I'm under the impression we are not talking about the same 
configuration. For me the premise of this discussion was to have a 
stable branch and a development branch. Bugfixes are done on the stable 
branch, new features or bug fixes too drastic for stable happen on 
development. To get the bugfixes from stable to development the stable 
branch is regularly merged into development. Regularly being the key 
here to avoid merges that become too complicated. In this scenario not 
"backports" happen from development to stable,  but bugfixes still get 
forward-ported to development.

Perhaps some drawings may help. Consider this starting point:

- A - B - C    (development)
    \
       ----- D    (stable)

A is the last common commit between stable and development. Development 
has been going in for a while, resulting in commits B and C on that 
branch. Then a bugfix commit D is created on stable (not on development).

Bugfixes should also go into development, so at this point the stable 
branch is to be merged into development. First step of the merge: create 
a temporary branch on stable (we want stable to remain an independent 
branch after the merge:

- A - B - C    (development)
    \
       ----- D    (stable, tmp-branch)

Then merge this tmp-branch into development, possibly fixing any merge 
conflicts. These merge conflicts would have been there in the 
backport/cherry-pick scenario as well, so nothing new.

- A - B - C - D'    (development, tmp-branch)
    \              /
       ----- D -        (stable)

The tmp-branch is discarded now, it only served for the merging. More 
development continues on development and at some point another bugfix 
lands on stable:

- A - B - C - D' - E - F    (development)
    \              /
       ----- D ---------- G    (stable)

Same dance. Setup temporary branch, merge it into trunk potentially 
resolving conflicts. Given commit D is already merged, I assume that git 
will only take the differences in commit G into account for the merge, 
resulting in this new picture:

- A - B - C - D' - E - F - G'    (development)
    \              /                /
       ----- D ---------- G -        (stable)

It looks pretty much like the inverse of our current backport strategy 
with the same merge conflict issues as cherry-picking. The big advantage 
in this process is that the git history shows you in one glance which 
bugfixes are not merged into development yet.

Note that refinement is possible by requiring separate branches for most 
development, that then have to be merged into stable or development 
after review. Kind of re-adds the AUDIT procedure that currently is no 
longer in use.

Possibly this process is flawed in other ways I'm missing. I'm happy to 
learn about them.

Geert