On Wed, Jan 25, 2012 at 10:09 AM, Pascal Chambon <[email protected]> wrote: > > > Le 22/01/2012 17:56, lkcl luke a écrit : >> On Sun, Jan 22, 2012 at 2:00 PM, Pascal Chambon<[email protected]> wrote: >>>> ... p.s. thank you. >>>> >>> You're welcome. >>> >>> But actually there are some very nasty conflicts around nested tuples >>> assignments, and "for" loops... Dan's And Kees' versions of these (+ the >>> corresponding unit tests) have different approaches, aggravatated by the >>> fact they don't use the same parser exactly. >>> So far all merge attempts resulted in hard-to-debug issues (uncaught >>> javascript exceptions and the like). >> arse. >> >> can you take portions of it? >> >> were the commits done in a controlled fashion i.e. fixing specific >> issues one-by-one? >> >> l. > > Yep but the interesting part is actually the conflicting one. As every > merge conflict, it'll need a good understanding of the working of both > evolutions. >
oh bloody 'ell :) ok - are there bits that you can take - right now - on which nothing else is dependent? i.e. can you forward-port the "easy bits" and leave the knotty bit for later? basically i don't want yet _more_ conflicts to come about. l.
