Elijah Newren <newren@xxxxxxxxx> writes:
> 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?
--
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