fileset: suppress EACCES while reading arbitrary paths via filectx API
On Windows, EACCES is raised in place of EISDIR. This patch simply adds
EACCES to the list of errors to be ignored since I think it's okay for
filesets to treat inaccessible working-copy files as not existing.
merge: do the trivial resolution after updating sparse checkout
In merge, we do trivial resolution for files which were deleted on one side and
changed on other. When sparse extension in involved that file might not be
present in wdir and trivial resolution can lead to file not found error. This
patch make sure we updates the sparse checkout before doing the trivial
resolution.
This fixes the test failure demonstrated in previous patch.
Differential Revision: https://phab.mercurial-scm.org/D3984
sparse: add test showing `hg merge` is broken while using sparse extension
This patch adds a test to demonstrate that `hg merge` is broken in some cases
while using sparse extension.
The case is when you have a file which is:
* modified between current wdir parent and merge base
* deleted between merge base and merge destination
* excluded from sparse checkout
Doing `hg merge` results in file not found error. Next patch will fix this.
Differential Revision: https://phab.mercurial-scm.org/D3983
context: use hex nodeid in error about filtered node
I went a little too far in my cleanup in
9231148ea599 (context:
convert to hex for error message only for 20-byte changeid,
2018-04-06). I missed that the case where a binary nodeid refers to a
filtered node.
Differential Revision: https://phab.mercurial-scm.org/D3987
doc: fix underline length for config title (
issue5949)
This was an error in the initial commit.
Thanks go to Marcel Svitalský for reporting the bug.
clone: process 'lookup' return as an arbitrary symbol
In theory, checkout is expected to be a node here because it was returned by
peer.lookup.
In practice, multiple important extensions (like hg-git, hg-subversion) use
peers not backed by a mercurial repository where lookup cannot return a node.
Allowing arbitrary symbols is necessary to make these extensions working with
4.7.
We should probably introduce a new API in Core to have these extensions to
work without abusing the lookup API. In the meantime, a small change to
restore compatibility in 4.7 seems in order.