lfs: clarify pointer validation error messages
It wasn't obvious that LFS was involved from the error messages when `hg verify`
fails.
terse: pconvert() entries added to the temporary terse dict for Windows
Recent additional testing revealed this problem on Windows:
--- tests/test-status.t.err
+++ tests/test-status.t.err
@@ -109,7 +109,7 @@
tweaking defaults works
$ hg status --cwd a --config ui.tweakdefaults=yes
- ? .
+ ? ../a/
? ../b/
? ../in_root
$ HGPLAIN=1 hg status --cwd a --config ui.tweakdefaults=yes
@@ -120,7 +120,7 @@
? b/in_b (glob)
? in_root
$ HGPLAINEXCEPT=tweakdefaults hg status --cwd a --config ui.tweakdefaults=yes
- ? .
+ ? ..\a\
? ../b/
? ../in_root (glob)
AFAICT, the status list (input and output here) is always in '/' format. The
'\' printed output on Windows is because each file is run through repo.pathto()
-> dirstate.pathto() -> util.pathto(). (And that function states that the
argument uses '/' separators.)
I fixed a similar issue in
362096cfdb1f, and given the apparent need for these
strings to be in '/' format, I wonder if cmdutil.dirnode() should be rewritten
to avoid os.path.join(). But it looks like all entries added to the temporary
terse dict should use '/' now, and cmdutil.tersedir() looks like the only user.
phases: define an official tuple of phases we do not share
Same motivation as for `mutablephases`, having a single definition helps with
updating phases logic.
phases: define an official tuple of mutable phases
Such tuple was already manually defined in a couple of place. Having an
official definition makes it easy to introduce of new phases.
repoview: use 'phasecache.getrevset' when computing 'unserved' filter
This reuses a precomputed set, being much faster than manual iteration.
Computing the "unserved" filter speed up by 55%.
before: wall 0.014671 comb 0.020000 user 0.020000 sys 0.000000 (best of 180)
after: wall 0.006623 comb 0.010000 user 0.010000 sys 0.000000 (best of 401)
The "unserved" filter is used to restrict the revisions client can pull from a
server. (eg: secret changesets)
graft: drop --user and --date values info from hint in case of conflicts
After previous patch, we have started preserving user and date values in
graftstate and reusing them during `hg graft --continue`. Now passing --user and
--date again with --continue makes no sense. Let's drop them from the hint.
Differential Revision: https://phab.mercurial-scm.org/D3660
graft: reuse --user and --date values in `hg graft --continue` (BC)
Reading the user and date information from graftstate during `hg graft
--continue` will help us in preserving the user and date arguments passed when
`hg graft` was called. This patch reads that information and reuses that while
running `hg graft --continue`. So after this patch, --user and --date values are
preserved even if conflicts occur and user don't need to pass them again.
The test changes demonstrate the fix.
This is a backward incompatible change but I think of this more as a bug fix.
Also thinking about removing the line from `hg help graft` which says --continue
does not reapply other flags but need to check what are the other flags which
needs to be preserved.
Differential Revision: https://phab.mercurial-scm.org/D3659
tests: add test showing --continue not preserving --date and --user flags
This patch adds test showing that we don't preserve the user passed --date and
--user values in `hg graft`. I was fixing that and realized this is untested.
Adding tests before so that behavior change or the fix is easy to realize.
Differential Revision: https://phab.mercurial-scm.org/D3658
graft: store user passed date and user information in graftstate
Right now, `hg help graft` says:
The -c/--continue option does not reapply earlier options, except for --force.
which should be treated as a bug.
A good user experience is that the commands remember the arguments passed
initially and preserve them during `hg graft --continue`.
This patch starts storing the user and date information in graftstate if user
passed it. Upcoming patches will make sure we preserve that information during
--continue and them don't allow user to pass any new arguments with --continue.
I don't think there is any another `--continue` flag which allows new options to
be passed with it.
Differential Revision: https://phab.mercurial-scm.org/D3657