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

[Elijah Newren <newren@gmail.com>]

On Tue, Aug 24, 2010 at 4:47 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Wed, Aug 25, 2010 at 8:37 AM, Jonathan Nieder <jrnieder@gmail.com> 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?