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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2010, 19:27 UTC
Message-ID: <7vpqx6qypx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTinsNvVup43B6nQtU6dvJy789n8kQm6N6na0J9oa@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 12 quoted lines

> 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).
>
> Here's my understanding, though it might have holes:
>
> If you have a narrow/subtree clone, it means that you only have the
> data for a certain paths.  I'm assuming that also meant you would only
> allow modifying those paths.  In other words, you have no changes
> outside the narrow tree.  Because of that, I think you can handle
> paths outside the narrow region using trivial-merge logic ...

I think you can do a merge only once, but after that you would be lost.

Suppose you forked from commit A, narrowed to one subdirectory and created B (iow, diff(A, B) contains only changes to that subdirectory). Somebody else worked on the whole tree and queued commit C on top of A.

      B---?
     /   /
 ---A---C

Your merge between B and C that uses A as the common ancestor can take all changes outside the subdirectory from C (but you need to know all the tree object names in C near the top outside your area). So far, so good.

While this was going on, somebody else also forked from A and made changes that touch both inside and outside your area, and its tip commit is E.

      B---D---?
     /   /   /
 ---A---C   /
     \     /
      o---E

Now you want to merge changes made on the branch that leads to E to your copy. How would we do that?

You cannot merge D and E without having enough information necessary to make a merge between C and E with full tree, can you?