Since we've dropped a str cast at write() by 7dbd3db608c5, ui.prompt() should
convert default to '' if it is None. Otherwise, write() would fail with
"TypeError: object of type 'NoneType' has no len()".
This patch includes the tests for both interactive and non-interactive cases
because "ui.askusername" was never tested.
cf6cc5344afa added 'ignoresub' argument to ui.configitems(), but zeroconf
wrapper wasn't updated. It caused the following crash:
Traceback (most recent call last):
File "bin/hg", line 43, in <module>
mercurial.dispatch.run()
File "lib/python/mercurial/dispatch.py", line 54, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
File "lib/python/mercurial/dispatch.py", line 120, in dispatch
ret = _runcatch(req)
File "lib/python/mercurial/dispatch.py", line 191, in _runcatch
return _dispatch(req)
File "lib/python/mercurial/dispatch.py", line 924, in _dispatch
cmdpats, cmdoptions)
File "lib/python/mercurial/dispatch.py", line 681, in runcommand
ret = _runcommand(ui, options, cmd, d)
File "lib/python/mercurial/extensions.py", line 195, in closure
return func(*(args + a), **kw)
File "lib/python/hgext/zeroconf/__init__.py", line 180, in cleanupafterdispatch
return orig(ui, options, cmd, cmdfunc)
File "lib/python/mercurial/dispatch.py", line 1055, in _runcommand
return checkargs()
File "lib/python/mercurial/dispatch.py", line 1015, in checkargs
return cmdfunc()
File "lib/python/mercurial/dispatch.py", line 921, in <lambda>
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File "lib/python/mercurial/util.py", line 991, in check
return func(*args, **kwargs)
File "lib/python/mercurial/commands.py", line 5405, in paths
pathitems = sorted(ui.paths.iteritems())
File "lib/python/mercurial/util.py", line 723, in __get__
result = self.func(obj)
File "lib/python/mercurial/ui.py", line 619, in paths
return paths(self)
File "lib/python/mercurial/ui.py", line 1099, in __init__
for name, loc in ui.configitems('paths', ignoresub=True):
File "lib/python/mercurial/extensions.py", line 195, in closure
return func(*(args + a), **kw)
TypeError: configitems() got an unexpected keyword argument 'ignoresub'
We have no test coverage for zeroconf, so I've added a minimal test that
could reproduce this problem.
Internal _matchfiles() function can take bunch of arguments, which would
lead to a maximum recursion depth error. This patch avoids the excessive
stack use by flattening 'list' nodes beforehand.
Since getlist() no longer takes a nested 'list' nodes, _parsealiasdecl()
also needs to flatten argument list, "aliasname($1, $2, ...)".
This backs out changeset fd794e885a9e9.
There are some extra fields that absolutely should not be preserved, like the
convert_revision field introduced by the convert and hgsubversion extensions.
The problem with extensions blacklisting certain extra fields is that they
might not be enabled at the time the amend is performed.
In the long run we probably want separately marked transferable and
non-transferable extra fields, but for now restore the old Mercurial 3.6
behavior.
On Solaris, recvmsg() is provided by libsocket.so. We could try hard to look
for the library which provides 'recvmsg' symbol, but it would make little sense
now since recvfds() won't work anyway on Solaris. So this patch just disables
_recvmsg() on such platforms.
Thanks to FUJIWARA Katsunori for spotting this problem.
It appears that Solaris doesn't provide CMSG_LEN(), msg_control, etc. As
recvfds() is only necessary for chg, this patch just drops it if CMSG_LEN
isn't defined, which is the same workaround as Python 3.x.
https://hg.python.org/cpython/rev/c64216addd7f#l7.33
In 0413f674179e (verify: move file cross checking to its own function,
2016-01-05), "mflinkrevs = None" was moved into function, so the
reference was cleared there, but the calling function now held on to
the variable. The point of clearing it was presumably to free up
memory, so let's move the clearing to the calling function where it
makes a difference. Also change "mflinkrevs = None" to "del
mflinkrevs", since the comment about scope now surely is obsolete.
Rather than look for the lowest revision, see if the rebase state is tracking
the parents of this revision. Otherwise we can't handle multiple revisions in
one rebase that includes a merge revision.
Fixes issue5044.
Before this patch, text blocks changed in this patch are shown as just
continuous text blocks like below in HTML format.
Global configuration like the username setting is typically put into:
%USERPROFILE%\mercurial.ini
$HOME/.hgrc
This patch itemizes these text blocks to increase readability in HTML
format.
Global configuration like the username setting is typically put into:
- %USERPROFILE%\mercurial.ini (on Windows)
- $HOME/.hgrc (on Unix, Plan9)
Like as other platform sensitive container-ed text blocks, this patch
also adds explicit "on PLATFORM" information to each items for
readability in HTML format, even though output of "hg help config" on
command line seems a little redundant. For example, on Unix:
Global configuration like the username setting is typically put into:
- "$HOME/.hgrc" (on Unix, Plan9)
This patch fixes problems below:
- ":hg:" role should be followed by not '"' but '`'
- there is a help topic not "default-push" but "config.default-push"
Because "backout --merge" have to make a commit before merging, it doesn't
work with --no-commit. We could change "backout --merge" to make a merge
commit automatically, and --no-commit to bypass a merge commit, but that
change would be undesirable because:
a) it's hard to fix bad merges in general
b) two commits would be created with the same --message
So, this patch simply disables "--merge --no-commit".
In b89de5ee5b31 (changegroup: don't support versions 01 and 02 with
treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2
with treemanifest repos. What I had not considered was that it's
perfectly safe to pull *to* a treemanifest repo using any changegroup
version. As reported in issue5066, I therefore broke pull from old
repos into a treemanifest repo. It was not covered by the test case,
because that pulled from a local repo while enabling treemanifests,
which enabled treemanifests on the source repo as well. After
switching to pulling via HTTP, it breaks.
Fix by splitting up changegroup.supportedversions() into
supportedincomingversions() and supportedoutgoingversions().
In my patch series ending with rev c3f2eede6938 I switched most change/delete
conflicts to be handled at the resolve layer. .hgsubstate was the one file that
we weren't able to handle, so we kept the old code path around for it.
The old code path added .hgsubstate to one of the other lists as the user
specifies, including possibly the 'g' list.
Now since we did this check after converting the actions from being keyed by
file to being keyed by action type, there was nothing that actually removed
.hgsubstate from the 'cd' or 'dc' lists. This meant that the file would
eventually make its way into the 'mergeactions' list, now freshly augmented
with 'cd' and 'dc' actions.
We call subrepo.submerge for both 'g' actions and merge actions.
This means that if the resolution to an .hgsubstate change/delete conflict was
to add it to the 'g' list, subrepo.submerge would be called twice. It turns out
that this doesn't cause any adverse effects on Linux due to caching, but
apparently breaks on other operating systems including Windows.
The fix here moves this to before we convert the actions over. This ensures
that it .hgsubstate doesn't make its way into multiple lists.
The real fix here is going to be:
(1) move .hgsubstate conflict resolution into the resolve layer, and
(2) use a real data structure for the actions rather than shuffling data around
between lists and dictionaries: we need a hash (or prefix-based) index by
file and a list index by action type.
There's a very tiny behavior change here: collision detection on
case-insensitive systems will happen after this is resolved, not before. I think
this is the right change -- .hgsubstate could theoretically collide with other
files -- but in any case it makes no practical difference.
Thanks to Yuya Nishihara for investigating this.
We've discovered an issue with this flag during certain kinds of rebases. When:
(1) we're rebasing while currently on the destination commit, and
(2) an untracked or ignored file F is currently in the working copy, and
(3) the same file F is in a source commit, and
(4) F has different contents in the source commit,
then we'll try to merge the file rather than overwrite it.
An earlier patch I sent honored the options for these situations as well.
Unfortunately, rebases go through the same flow as the old, deprecated 'hg
merge --force'. We'd rather not make any changes to 'hg merge --force'
behavior, and there's no way from this point in the code to figure out whether
we're in 'hg rebase' or 'hg merge --force'.
Pierre-Yves David and I came up with the idea to split the 'force' flag up into
'force' for rebases, and 'forcemerge' for merge. Since this is a very
disruptive change and we're in freeze mode, simply undocument the options for
this release so that our hands aren't tied by BC concerns. We'll redocument
them in the next release.
Before this patch, "hg pull --update" doesn't advance current active
bookmark correctly, if pulling itself doesn't advance it, even though
"hg pull" + "hg update" does so.
Existing test for "pull --update works the same as pull && update" in
test-bookmarks.t doesn't examine this case, because pulling itself
advance current active bookmark before actual updating the working
directory in that test case.
To advance current active bookmark at "hg pull --update" correctly,
this patch examines 'movemarkfrom' instead of 'not checkout'.
Even if 'not checkout' at the invocation of postincoming(), 'checkout'
is overwritten by "the revision to update to" value returned by
destutil.destupdate() in such case. Therefore, 'not checkout'
condition means "update destination is revision #0", and isn't
suitable for examining whether active bookmark should be advanced.
Even though examination around "movemarkfrom == repo['.'].node()" may
seem a little redundant just for this issue, this makes it easier to
compare (and unify in the future, maybe) with the same logic to update
bookmark at "hg update" below.
if not ret and movemarkfrom:
if movemarkfrom == repo['.'].node():
pass # no-op update
elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()):
ui.status(_("updating bookmark %s\n") % repo._activebookmark)
else:
# this can happen with a non-linear update
ui.status(_("(leaving bookmark %s)\n") %
repo._activebookmark)
bookmarks.deactivate(repo)
Previously, if the largefile was deleted at the time of a commit, the standin
was silently not updated and its current state (possibly garbage) was recorded.
The test makes it look like this is somewhat of an edge case, but the same thing
happens when an `hg revert` followed by `rm` changes the standin.
Aside from the second invocation of this in lfutil.updatestandinsbymatch()
(which is what triggers this test case), the three other uses are guarded by
dirstate checks for added or modified, or an existence check in the filesystem.
So aborting in lfutil.updatestandins() should be safe, and will avoid silent
skips in the future if this is used elsewhere.
There were two mistakes: one was accidental reuse of the fclnode
variable from the loop gathering file nodes, and the other (masked by
that bug) was not correctly handling deleted directories. Both cases
are now fixed and the test passes.
On repos with lots of heads, the filelog() code could spend several
minutes decompressing manifests. This change instead tries to
efficiently scan the changelog for candidates and decompress as few
manifests as possible. This is a regression introduced in 3.3 by the
linkrev adjustment code. Prior to that, filelog was nearly instant.
For the repo in the bug report, this improves time of a simple log
command from ~3 minutes to ~.5 seconds, a 360x speedup.
For the main Mercurial repo, a log of commands.py slows down from
1.14s to 1.45s, a 27% slowdown. This is still faster than the file()
revset, which takes 2.1 seconds.
The largefiles extension needs to set lfstatus for this status call. Otherwise,
if a missing largefile is explicitly named, a confusing message is issued that
says the largefile wasn't found, followed by another that says nothing changed.
The change in 6fce9a02f069 to handle a normal -> largefile switch was too
aggressive in preserving the original matcher names. If a largefile is
explicitly provided by the user, but only the standin exists in dirstate, then
only the standin can be committed.
There's still maybe an issue when the largefile is deleted outside of Mercurial:
$ rm large
$ hg ci -m "oops" large
large: The system cannot find the file specified
nothing changed
[1]
In a4119550f1e1 (context: clarify why we don't compare file contents
when nodeid differs, 2016-01-12), I also changed "node2 != _newnode"
into "self.rev() is not None". I don't remember why. They are similar,
but the former also catches the case where the file is clean in the
dirstate (so node2 is not _newnode), but different from the "other"
context. This resulted in unnecessary file content comparison a few
lines further down in the code. Let's just back out the code change.
Thanks to Durham Goode for spotting this.
In this case, a template is parsed recursively with no thunk for lazy
evaluation. This patch prevents recursion by putting a dummy of the same name
into a cache that will be referenced while parsing if there's a recursion.
changeset = {files % changeset}\n
~~~~~~~~~
= [(_runrecursivesymbol, 'changeset')]
It would be nice if we could detect recursion at the parsing phase, but we
can't because a template can refer to a keyword of the same name. For example,
"rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a
keyword or a template while parsing.
In 7a1ccfe03f74 (treemanifests: set bundle2 part parameter indicating
treemanifest, 2016-01-08), I didn't realize I had to set the parameter
separately for getbundle and unbundle. Having the parameter there on
push allows us to push to an empty repo and have the requirements
updated correctly.
Before this patch, the help bar in crecord wouldn't be printed correctly when
the terminal window didn't have enough column to display it. This patch adds
logic to make sure that the help bar message is always displayed. We use an
ellipsis when it is not possible to display the complete message.
In the crecord help dialog, the toggle all option was wrongfully documented.
Instead of using 'a', one must use 'A' to toggle all the hunks. The crecord
header that is always displayed on the screen contains the right shortcut and
does not need to be changed.
This patch improves the error messages raised when an OSError occurs, since
simply re-raising the exception can be both confusing and misleading. For
example, if "hg identify" is run inside a repository that contains a Git
subrepository and the git binary could not be found, it'll exit with the message
"abort: No such file or directory". That implies "identify" has a problem
reading the repository itself. There's no way for the user to know what the
real problem is unless they dive into the Mercurial source, which is what I
ended up doing after spending hours debugging errors while provisioning a VM
with Ansible (turns out I forgot to install Git on it).
Descriptive errors are especially important on Windows, since it's common for
Windows users to forget to set the "Path" system variable after installing Git.
After 313b8d61b548 graph canvas width is decided once on the initial rendering.
However, after graph page gets scrolled down to load more, it might need more
horizontal space to draw, so it needs to resize the canvas dynamically.
The exact problem that this patch solves can be seen using:
hg init testfork
cd testfork
echo 0 > foo
hg ci -Am0
echo 1 > foo
hg ci -m1
hg up 0
echo 2 > foo
hg ci -m2
hg gl -T '{rev}\n'
@ 2
|
| o 1
|/
o 0
hg serve
And then by navigating to http://127.0.0.1:8000/graph/tip?revcount=1
"revcount=1" makes sure the initial graph contains only revision 2. And because
the initial canvas width takes only that one revision into count, after the
(immediate) AJAX update revision 1 will be cut off from the graph.
We can safely set canvas width to the new value we get from the AJAX request
because every time graph is updated, it is completely redrawn using all the
requested nodes (in the case above it will use /graph/2?revcount=61), so the
value is guaranteed not to decrease.
P.S.: Sorry for parsing HTML with regexes, but I didn't start it.
Laurent's commit 56cdfddbd2ed still suffers from a race: by the
time the "job" function tries to assign to channels[channel], that
list has been truncated to empty. The result is that every job
thread raises an IndexError.
Earlier, I tried an approach of correctly locking channels, but
that caused run-tests to hang on KeyboardInterrupt sometimes.
This approach is strictly hackier, but seems to actually work
reliably.
