Re: [RFD PATCH 00/32] subtree clone v2

[Elijah Newren <newren@gmail.com>]

Replying to myself...

On Tue, Aug 24, 2010 at 10:37 PM, Elijah Newren <newren@gmail.com> wrote:
<snip>
> outside the narrow tree.  Because of that, I think you can handle
> paths outside the narrow region using trivial-merge logic:  From
> Documentation/technical/trivial-merge.txt, I think the relevant cases
> are 2, 3, 8, 10, 13, or 14.  13 & 14 already have a specified
<snip>
> That only leaves cases 2 & 3 as being slightly tricky -- if a path on
> one side of the merge started empty and ended empty, it would seem to
> make sense that the non-empty path on the other side would be the
> resolution.  We can't do that in the non-narrow clone case because the
> non-empty path may have been created due to a rename and we'd like to
> have changes follow the rename appropriately.  However, in the narrow
> clone case, one can't rename from a path you don't have to a path you
> do, so this possibility is eliminated.

I just realized I was assuming the path was empty in the merge base
and in upstream, but non-empty on the side of the merge corresponding
to the local sparse/narrow repository.  My wording certainly reflected
that assumption.  If so, I still think what I said was correct.  If
not, it's slightly more subtle.  If the non-empty side is upstream,
then it may be a rename case that needs special handling.  If it's a
rename from a path outside our subtree (and we can somehow detect this
case), then although we don't have the data to do any special
handling, it wouldn't be necessary since we did not modify either the
source or destination of the rename.  The tricky case is if it's a
rename from a path within our subtree to a file outside; we'd only be
able to handle such situations if there was no modification other than
the rename.  Unfortunately, we can't distinguish between (1) renames
from paths outside our subtree to outside our subtree and (2) renames
plus changes from paths inside our subtree to outside our subtree.

That puts us in a bit of a pickle for the empty->empty vs. non-empty
case.  We can only resolve it if the non-empty side is in our subtree,
or if we decide to just ignore renames in our merges.