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

John Ralls jralls at ceridwen.us
Thu Jan 31 14:40:35 EST 2013


On Jan 31, 2013, at 10:22 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

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

This breaks down when B and C affect the same code that D does. Obviously you resolve those conflicts in favor of the development branch when you merge D. No problem, right? Well, you have to resolve them again for every subsequent merge. That snowballs into "too hard" after a few dozen changes, as my merge of 2.4 into trunk demonstrated.

Regards,
John Ralls




More information about the gnucash-devel mailing list