(Just finishing an unfinished sentence...)
I (Julian Foad) wrote: > I (Julian Foad) wrote: >> This is great. You're right, the main thing seems to be that >> find_symmetric_merge is currently only fetching and analyzing >> the branch-root mergeinfo. It needs to fetch and analyze all >> mergeinfo on the branch, finding a merge base for each subtree, >> and proceed something like this: >> >> * If every base found is on the source branch: >> -> choose the oldest base, and >> -> pass this base to the "sync merge" code path. > > As an interim measure, r1349322 passes the YCA as the "source-left" > location, every time it does a sync-style merge. This makes it find and > merge > any subtrees that need revisions merged, even revisions before the merge-root > path's base, and so fixes two of the four tests that were failing. > > To do the rest of this, we need to > > (a) Upgrade the base-finding code to find the base for every subtree, not > just > for the merge-root path. > > (b) Write logic that separates these three cases (the three "*" > bullet points in the quoted text here). > > (c) Write ... error reporting code that describes the problem understandably for human consumption, that perhaps suggest what to do next, like reintegrate already does in some cases. - Julian >> * If the same base is found for all subtrees >> and this base is on the target branch: >> -> pass this base to the "reintegrate" code path. >> >> * If different bases are found for different subtrees >> and any base is on the target branch: >> -> complain like "reintegrate" does in 1.7. > > > Actually, existing 1.7 "sync" and "reintegrate" don't > complain about all such cases: a "sync" simply ignores subtree > mergeinfo in the opposite direction from the merge, and "reintegrate" > simply ignores subtree mergeinfo in the same direction as the merge. We > probably want to error out, reporting the reason, in those cases too; I'll > write about that in a separate email. > > > - Julian
