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

From: Elijah Newren <newren@gmail.com>
Date: Aug 25, 2010, 20:43 UTC
Message-ID: <AANLkTi=rt5ho9EXg7_NF+JqPW=cs8yqAHqm5+mPooYcC@mail.gmail.com>
In-Reply-To: <7vpqx6qypx.fsf@alter.siamese.dyndns.org>

On Wed, Aug 25, 2010 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote: <snip>

Show 34 quoted lines

>> 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?

Ah, now I think I see what Duy was getting at; thanks for making that clear.

You are correct, of course[1]. Failing merges with "not-enough-information-available" will sometimes be a fact of life with sparse/narrow/subtree/partial/whatever clones[2] -- either that or "server-side merging" as Duy suggests (though I personally am not a fan of that). I was just pointing out that I think we're not limited to a single merge ever; for example, if I understand correctly, if someone else merges C & E then you'll be able to merge from them[3] (and thus, you'll be able to merge "more than once").

Elijah

[1] Outside your subtree, D does not match the merge-base A, thus so you can't employ 'trivial merge' logic and you don't have the data for any other kind of merge.

[2] As noted as item 7 at http://article.gmane.org/gmane.comp.version-control.git/152020.

[3] This is because outside your subtree, D would match the new merge-base (C), allowing you to use trivial merge logic again.