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

[Elijah Newren <newren@gmail.com>]

Hi,

On Tue, Aug 24, 2010 at 11:21 PM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On Wed, Aug 25, 2010 at 2:37 PM, Elijah Newren <newren@gmail.com> wrote:
<snip>
>> I'm not sure I follow.  Are you allowing changes outside the narrow
>> tree to occur?  If you're not, I would have assumed that repeated
>> pulls just work, without any need to talk to the server, using a
>> resolve-like strategy (with no special rename detection).
>
> I don't. But I can't stop all other users (who use full repos) change
> outside the narrow tree and push their changes back upstream. When
> narrow user pulls from upstream again, the tree outside narrow tree
> might be not the same as before.

Sure, they will modify paths outside your subtree, but you know that
you didn't do so.  So if you neglect renames then the situation is
pretty simple:

Merge-side: ancestor    you         upstream
            --------    --------    --------------
Sha1sum:    ancestor    ancestor    new-stuff

Which could be true for either a file or a tree.  Either way, if you
ignore renames, then the trivial merge is 'new-stuff' for any such
blob/tree.  (Yeah, you'd have to create a new merge algorithm that
does 'trivial' merges at tree levels in addition to file levels, but
the concept is relatively simple at least.)

After your merge, a subsequent pull would look like this at the same
file/tree path:

Merge-side: ancestor    you         upstream
            --------    --------    --------------
Sha1sum:    new-stuff   new-stuff   newer-stuff

For which the resolution would be 'newer-stuff' (again, ignoring the
problems that renames could cause, which I discussed elsewhere).

Unless, of course, I'm missing something still...