On Fri, Apr 16, 2010 at 2:41 PM, Paul Burba <ptbu...@gmail.com> wrote:
> Ok, that looks fine (to me at any rate). But if you look at the test, > you might notice that merge_tests-63.files/mu doesn't actually have > any mergeinfo prior to the merge, nor does the root > merge_tests-63.files for that matter. What is going on here is an > unintended side effect of dealing with shallow merge targets. Since > merge_tests-63.files is at depth=files, is treated as if it does have > mergeinfo, since its immediate parent is missing its directory > children, once the merge is complete it will get non-inheritable > mergeinfo describing the merge. So merge_tests-63.files/mu must get > its own explicit mergeinfo. The CHILDREN_WITH_MERGEINFO array that > merge.c uses to keep track of all subtrees with mergeinfo just > includes merge_tests-63.files/mu right from the beginning, knowing > that it will end up with mergeinfo at the end of the merge...(well > that was the original intent, but in 1.7, since unaffected subtrees > won't have their mergeinfo updated, children of shallow parents won't > always have their mergeinfo updated. I'll fix this. Scratch that last bit, there is nothing to fix. If merge_tests-63.files/mu gets a notification, then by definition the merge has touched it and it *will* have mergeinfo. Paul
