Hi,
On Tue, Aug 24, 2010 at 11:21 PM, Nguyen Thai Ngoc Duy
<pclouds@xxxxxxxxx> wrote:
> On Wed, Aug 25, 2010 at 2:37 PM, Elijah Newren <newren@xxxxxxxxx> 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...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html