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

John Ralls jralls at ceridwen.us
Thu Jan 31 16:49:33 EST 2013


On Jan 31, 2013, at 1:22 PM, Yawar Amin <yawar.amin at gmail.com> wrote:

> Hi John,
> 
> On 2013-01-31, at 14:40, John Ralls <jralls at ceridwen.us> wrote:
> 
>> [...]
>> 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,
> 
> I really doubt this is the case. Merging a branch into another multiple times in history is a fundamental git workflow and is rightly touted as one of its strengths.
> 
>> as my merge of 2.4 into trunk demonstrated.
> 
> I think your merge demonstrated that cherry-picking/backporting causes git to see conflicting changes to the same lines and borks merge attempts.

Not backporting (that's not a git operation), but cherry picking because a cherry-pick doesn't have multiple parents like a merge does. 

Regards,
John Ralls




More information about the gnucash-devel mailing list