Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Andreas Krey wrote: >> If in the merge A->B you had discarded some/most changes as being >> irrelevant, committed, then done some more work on branch B then the >> merge back must not use 1.2 since 1.2 is not the logical ancestor > > True. But when you don't actually bring in everything from 1.2 then > there should not be a merge arrow for that action in the first place. That depends. Maybe the same functionality has been added differently on the branch and on the trunk. (Say both code lines needed to buffer/queue some event that previously was handled directly, for different reasons.) Obviously when you merge the code, you throw away one of the two implementations (or both, and create an equivalent third). Merging (as I see it) is not "putting every code that's in both code lines into one", it's "making the code do everything that's done in both code lines, in a way that makes sense in the light of the changes in both code lines". Which may result in substantial code changes in one or both code lines during the merge. In any case, there seem to be scenarios where merging back-and-forth isn't safe; the disagreement is which these are exactly. There is a solution (unidirectional merge, with a branch copy at the end) that provides all the benefits without the dangers of running such back-and-forth merges. I fail to see the actual problem :) Gerhard