Branko Čibej wrote: > On 09.05.2012 18:54, Julian Foad wrote: >> The second group concerns merging changes into a file from its own (past or > future) history; this kind of merge isn't a 'sync' so shouldn't > be handled by this code path. > > We keep coming back to this ... I still don't understand /why/ we would > need more than one merge algorithm, or why the symmetric merge would not > work correctly in this case.
Well, I was hand-waving a bit, meaning to dismiss this as some kind of simple side-issue, which I think it is. I agree that, in principle, there need not be any other kind of merge. In practice, however, we might want to bypass the part of the algorithm that traverses the merge graph and branching history to find an appropriate base, if we have a degenerate case where we know in advance what base to use, and if the source and target branches do not both exist as separate branches in the repository. In this case, the merge base is always the youngest common ancestor (YCA) which is the WC pristine version. The target branch consists only of the YCA followed by the WC working version; there is no commit on the target branch, not even a branch-creation commit, so it is a somewhat degenerate case of a 'branch'. rev 1 2 [o = a repository node] | | [w = a WC working node] | o / ---o \ | w | | | the WC working version YCA=the WC pristine version Nevertheless, I agree with you that it's best if the algorithm can handle such cases. It's not all *that* special. Looking more closely at these test failures, the (initial) problem is just a difference between expecting the merge notification to say "Merging r2" when it actually says "Merging differences between repository URLs", and that is caused by the symmetric-merge code failing to find a base on the source branch. I suspect (but haven't delved deeper yet) that I can adjust the find-a-base code to report revision 1 as the base-on-source [1] in this case, and thus these merges yield the previously expected notification and results. [1] And I will change the code to prefer a base-on-source over a base-on-target when they are the same location. At the moment, the subsequent code path depends explicitly on whether we chose a base-on-source or a base-on-target, and gives a different notification, although in theory (and, I hope, later in practice) the same code path should handle either way. - Julian
