Hi John, On 2013-01-31, at 14:40, John Ralls <[email protected]> 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. Regards, Yawar _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
