On Jan 31, 2013, at 1:22 PM, Yawar Amin <yawar.a...@gmail.com> wrote:
> Hi John, > > On 2013-01-31, at 14:40, John Ralls <jra...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
