It's worth noting that when phase data is being requested, the
server will also emit changeset records for nodes in the bases
specified by the "noderange" argument. This is to ensure that
phase-only updates for nodes the client has are available to the
client, even if no new changesets will be transferred.

Nice! That was a lot simpler than I expected. I expected some changes would be needed on the client to prevent it from stripping the existing file nodes, but I suppose is still does that and it still works because it re-applies that stripped bundle afterwards.

Probably a consequence of https://www.mercurial-scm.org/repo/hg/rev/a3dacabd476b or some other commit in that series.

FIWI, I don't think I would expect the .hg/hgrc of the source repo to be loaded. I don't think I'd be surprised if I configured an extension in the source repo and had to configure that in the share as well for it to work.

In D4549#69559, @pulkit wrote:

test-init.t and test-mq.t says hi!

In D4529#69177, @indygreg wrote:

Unfortunately we likely can never ship either the narrow or ellipsis capability as stable because it would confuse 4.7 clients, which will presumably have a different understanding of what narrow and ellipsis mean. But at least now it is clear from the strings that the feature is experimental and we have a way of versioning its semantics until it stabilizes.

In D4522#69130, @indygreg wrote:

Looking through this code a bit more, it appears that there is a not-in-core "remote expansion" wire protocol command that recognizes the include: prefix and asks the server to expand it. This series will stop that from working.

I didn't notice this at first because we have no tests for it.

I think Google's server relies on this feature.

@martinvonz how do you want to proceed? Should we nuke the include: feature in core? Or do you want me to refactor this series to support the include: on user-provided commands?

In D4521#69012, @pulkit wrote:

In D4521#69005, @martinvonz wrote:

checking bundle2 capability which does not scale outside of bundle2 world.

Is your goal to use narrowness without ellipsis nodes with a changegroup1 server? Can we split this patch up so it just splits up the "narrow" capability into "narrow" and "ellipsis" and then we can consider cg1 support in a separate patch?

No, that's not a goal. The goal is to make a wireprotocol command and prevent using pull to exchange data atleast for non-ellipsis cases.

checking bundle2 capability which does not scale outside of bundle2 world.

Thanks!

In D4341#67539, @pulkit wrote:

Maybe the current state is not very helpful in reviewing. The traceback which I am trying to fix is this:

   $ hg merge
+  Traceback (most recent call last):
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/scmutil.py", line 161, in callcatch
+      return func()
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/dispatch.py", line 344, in _runcatchfunc
+      return _dispatch(req)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/dispatch.py", line 982, in _dispatch
+      cmdpats, cmdoptions)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/dispatch.py", line 728, in runcommand
+      ret = _runcommand(ui, options, cmd, d)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/dispatch.py", line 990, in _runcommand
+      return cmdfunc()
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/dispatch.py", line 979, in <lambda>
+      d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/util.py", line 1531, in check
+      return func(*args, **kwargs)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/commands.py", line 3785, in merge
+      labels=labels, abort=abort)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/hg.py", line 904, in merge
+      labels=labels)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/merge.py", line 2177, in update
+      stats = applyupdates(repo, actions, wc, p2, overwrite, labels=labels)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/merge.py", line 1584, in applyupdates
+      ms.add(fcl, fco, fca, f)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/merge.py", line 493, in add
+      self._repo.vfs.write('merge/' + hash, fcl.data())
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/context.py", line 1685, in data
+      return self._repo.wread(self._path)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/localrepo.py", line 1212, in wread
+      data = self.wvfs.read(filename)
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/vfs.py", line 78, in read
+      with self(path, 'rb') as fp:
+    File "/place/vartmp/hgtests.nx0HIy/install/lib/python/mercurial/vfs.py", line 409, in __call__
+      fp = util.posixfile(f, mode)
+  IOError: [Errno 2] $ENOENT$: '$TESTTMP/mvtest/a'
   abort: $ENOENT$: $TESTTMP/mvtest/a
   [255]

The error comes when we try to read a working-fctx which is not present in working directory. I don't think applyupdates is the right place to add logic about updating sparse checkouts. The best way I could figure out is that explicitly take care that f2 is loaded while merging.

In D4508#68864, @yuja wrote:

+ self._containsseen = set()
+ self._containsiter = iter(self)

Perhaps iter() needs to be extracted to a free function to avoid
reference cycle.