On Fri, Apr 16, 2010 at 2:41 PM, Paul Burba <ptburba_at_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
Received on 2010-04-16 21:29:34 CEST