On Wed, Aug 25, 2010 at 2:37 PM, Elijah Newren <newren@xxxxxxxxx> wrote: >>>> 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). I don't. But I can't stop all other users (who use full repos) change outside the narrow tree and push their changes back upstream. When narrow user pulls from upstream again, the tree outside narrow tree might be not the same as before. > 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. Trivial merge did not work outside narrow tree for me because I did not have all trees of a commit. So as soon as it steps on the narrow border, it has to stop (without retrieving full path to files outside narrow tree). trivial-merge.txt takes input as files, not directories. Given two directories (because we don't have further details what inside those directories), I don't know how to do trivial merge. > 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. Yes. But other people will change outside narrow tree, unfortunately. -- Duy -- 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