On Wed, Aug 25, 2010 at 1:27 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: <snip> >> 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. -- 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