On Tue, Aug 24, 2010 at 4:47 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Wed, Aug 25, 2010 at 8:37 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Nguyễn Thái Ngọc Duy wrote: >> >>> Patches 26..30 >>> Add upload-narrow-base command >>> rev-list: traverse some more trees to make upload-narrow-base happy >>> narrow-tree: add oldest_narrow_base() >>> Add command fetch-narrow-base >>> merge: support merging when narrow bases are different >>> >>> Remote merge part. >>> >>> Split a merge operation into two parts, the real merge will be done >>> within narrow tree. Conflicts can happen and be resolved in the narrow >>> index, locally. >>> >>> Everything outside narrow tree will be merged (trivially) by >>> server. Then server sends the base tree back, so join_narrow_tree() in >>> patch 20 can be used to create proper commit. >>> >>> Server can disable this remote merge feature, which means users are >>> forced to do rebase/fast-forward. Not too bad. >> >> Yikes. Naïve question (please forgive my laziness): is it possible to >> merge without remote contact in the boring case, when no changes have >> occured outside the narrow tree? > > That's possible (and is implemented in my series). But I guess as soon > as you do "git pull", the boring case is likely not applicable > anymore. 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: From Documentation/technical/trivial-merge.txt, I think the relevant cases are 2, 3, 8, 10, 13, or 14. 13 & 14 already have a specified resolution. There's already a comment in the file that cases 8 & 10 could validly be resolved as (empty), it just hasn't been done in the code as it tends to happen with the follow-up automatic merge anyway. That only leaves cases 2 & 3 as being slightly tricky -- if a path on one side of the merge started empty and ended empty, it would seem to make sense that the non-empty path on the other side would be the resolution. We can't do that in the non-narrow clone case because the non-empty path may have been created due to a rename and we'd like to have changes follow the rename appropriately. However, in the narrow clone case, one can't rename from a path you don't have to a path you do, so this possibility is eliminated. So, if my understanding is correct, then if you have no changes from upstream outside the sparse/narrow/whatever paths (where "paths" currently means a single tree in your current patches), I think you should be able to do a merge locally in that sparse clone. The end result will also have no changes from upstream outside those paths. Thus, you should be able to merge again. Does that seem reasonable? Am I missing anything? -- 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