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

[Buddha Buck]

I believe Geert's assumption is right -- git sees D as in the history
of both F and G, and won't try to remerge the A->D changes back into
G'.  This should be easy enough to test, just create a new git
repository, and make the appropriate set of edits to see if that's the
case.

The problem I can see is when the A->D changes and the A->B->C changes
conflict, the A->B->C changes get accepted into D', AND the D->G
changes also affect the same code, so that delta can't be cleanly
applied to F to get G'.



On Thu, Jan 31, 2013 at 3:54 PM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> On 31-01-13 20:40, John Ralls wrote:
>>
>> 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.
>
> Oh, boy, there's my wrong assumption. I assumed that after merging D into B
> and C, git would no longer consider D's changes for the next merge.
>
> If it is as you say, my proposed method would not work at all obviously.
>
> Geert
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel