Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 08:37:08 -0800] rev 44462
commit: print debug message when clearing dirstate and wdir clean
This case is a little weird, so let's have a debug message.
Differential Revision: https://phab.mercurial-scm.org/D8231
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 10:46:31 -0800] rev 44461
merge with stable
Augie Fackler <augie@google.com> [Thu, 05 Mar 2020 10:52:51 -0500] rev 44460
merge with stable
Augie Fackler <augie@google.com> [Wed, 04 Mar 2020 14:21:23 -0500] rev 44459
commands: switch one call of check_at_most_one_arg to strings
This opts hasn't been through the byteskwargs mulcher, so we can just use
strings here instead of bytes. Fixes the test changes from D8204 on Python 3,
which was the only place this was a problem.
Differential Revision: https://phab.mercurial-scm.org/D8222
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 11:32:27 -0800] rev 44458
cleanup: remove redundant clearing of mergestate in rebase and shelve
`repo.commit()` now clears the merge state even if it ends up not
creating a commit because there were no changes to commit.
Differential Revision: https://phab.mercurial-scm.org/D8197
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 11:32:02 -0800] rev 44457
commit: clear resolved mergestate even if working copy is clean
If the mergestate has resolved conflicts and a commit is successfully
created (either because there are changes in the working copy or
because ui.allowemptycommit=yes), we will also clear the merge
state. However, if the working copy is clean (and
ui.allowemptycommit=no), we leave the mergestate there. The user may
notice it in `hg resolve -l` output (but not in `hg status -v`
output). It's not clear how the user should clear it, but probably via
`hg co -C .`. It's also quite likely that they won't even notice it
and it will get cleared by a later `hg commit` (of unrelated
changes).
This patch makes it so that `hg commit` also clears resolved merge
conflicts even if the command doesn't end up writing a commit because
the working copy was empty. That's probably a little weird (commands
that abort should generally avoid changing the repo), but it still
seems mostly harmless, and it reduces the risk of more bugs like
https://bz.mercurial-scm.org/show_bug.cgi?id=5494. I just ran into a
version of that bug in the Evolve extension and that's what triggered
this series.
Differential Revision: https://phab.mercurial-scm.org/D8196
Matt Harbison <matt_harbison@yahoo.com> [Wed, 04 Mar 2020 00:45:54 -0500] rev 44456
phabricator: avoid a stacktrace when command arguments are missing
Previously, the TypeError wasn't properly converted to a SignatureError when
improper arguments were supplied to the inner function, because the stack depth
is 2 inside the vcrcommand decorator. The `__name__` and `__doc__` attributes
need to be reassigned to the new wrapper so that the help summary is available.
Differential Revision: https://phab.mercurial-scm.org/D8209
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:51:19 -0800] rev 44455
mq: don't tell user to commit merge that we already committed
Differential Revision: https://phab.mercurial-scm.org/D8000
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:28:37 -0800] rev 44454
merge: make hg.merge() take a context instead of a node
Many callers already have a repo, so we might as well pass
that. `merge.update()` will look up the context object later. This
patch is part of making it so we pass around the context object all
the way down instead.
I also removed the `repo` argument since it can be retrieved from the
context.
Differential Revision: https://phab.mercurial-scm.org/D7999
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 17 Jan 2020 21:22:23 +0300] rev 44453
debugbackupbundle: introduce command to interact with strip backups
This vendors backups extension from hg-experimental.
Listing backups and having some utility to apply them is nice. I know we have
obsmarkers now, but this will help a lot of end users who still uses strip until
we get evolve out of experimental.
Differential Revision: https://phab.mercurial-scm.org/D7932
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 10:56:40 -0500] rev 44452
phabricator: also check parent fctx for binary where it is checked for UTF-8
I don't know that this is necessary, but it seems obvious from the code checking
both the current and parent file for UTF-8 content that this was the intent.
Differential Revision: https://phab.mercurial-scm.org/D8221
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 10:46:43 -0500] rev 44451
phabricator: don't infer the old `fctx` in `notutf8()`
This is used along with `fctx.isbinary()` to gate `addoldbinary()`, so it seems
like a good idea to provide the caller similar control over the current and
parent filecontext. Unlike `addoldbinary()`, it doesn't need both previous and
current contexts at the same time, so make the caller responsible for testing
both cases, as appropriate. I haven't worked out all of the problems around
marking files as binary for move/remove/copy, but this will definitely help with
`--no-stack` too.
It also turns out to have been doing too much- in the remove case, it tested not
just the removed file in the parent context (which is what gets passed in that
case), but also in the parent of the parent context (which should be
irrelevant). The previous code also required the `fctx.parents()` check to work
in the add (but without rename) case. Now the add and remove cases test only
what they need to. But now that it is written this way, the fact that only the
current `fctx` is checked to be binary in the case of modification or being
renamed seems wrong.
Differential Revision: https://phab.mercurial-scm.org/D8220
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 12:42:07 -0500] rev 44450
phabricator: rename a variable to clarify that it is the parent filecontext
Differential Revision: https://phab.mercurial-scm.org/D8219
Matt Harbison <matt_harbison@yahoo.com> [Wed, 19 Feb 2020 13:33:58 -0500] rev 44449
phabricator: pass old `fctx` to `addoldbinary()` instead of inferring it
Currently, removed binaries aren't marked as binaries on the left side, which
sends the raw file view to a bad URL in the web interface. (See D8009) In order
to handle marking the file as binary in the removed case, both contexts need to
be provided by the caller, since there is no current fctx in the removed case.
Having an explicit old fctx will also be useful to support a `--no-stack` option
that rolls up the commit stack into a single review.
The bug isn't fixed with this change- there's a missing call to it in
`addremoved()` as well. But instead of spamming the list with a bunch of test
diffs, all of the missing binary issues will be fixed at once later.
Differential Revision: https://phab.mercurial-scm.org/D8218
Matt Harbison <matt_harbison@yahoo.com> [Wed, 04 Mar 2020 10:25:07 -0500] rev 44448
phabricator: make `hg phabread` work outside of a repository
This is similar to 16312ea45a8b and 2513f0f70a26- we don't need a repo, but will
load .hg/hgrc if inside one.
Differential Revision: https://phab.mercurial-scm.org/D8214
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 15:06:20 -0500] rev 44447
phabricator: refactor `phabread` to write all patches at once
This will be necessary to create a first class `phabimport` command. That
command requires a transaction, and will import all named patches within a
single transaction. But if Phabricator queries also happen within the
transaction, that leaves open the chance that an exception is raised, the
transaction is abandoned, and the next command that is run will complain about
needing to run `hg recover`.
Differential Revision: https://phab.mercurial-scm.org/D8135
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:14:44 -0500] rev 44446
phabricator: make `hg phabupdate` work outside of a repository
This is similar to 16312ea45a8b- we don't need a repo, but will load .hg/hgrc if
inside one.
Differential Revision: https://phab.mercurial-scm.org/D8208
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:28:40 -0500] rev 44445
phabricator: pass ui instead of repo to `userphids()`
Also not a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8207
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:08:01 -0500] rev 44444
phabricator: pass ui instead of repo to `querydrev()`
Also not a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8206
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:01:16 -0500] rev 44443
phabricator: pass ui instead of repo to `readpatch()`
This makes it a little clearer that it isn't a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8205
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 14:36:20 -0500] rev 44442
logtoprocess: avoid traceback when running long commands
$ hg log -r "present($(yes | tr -d '\n' | head -c 130000))" "$(yes | tr -d '\n' | head -c 5000)" --config extensions.logtoprocess= --config logtoprocess.commandfinish=whatever
Traceback (most recent call last):
File "/usr/bin/hg", line 67, in <module>
dispatch.run()
File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 111, in run
status = dispatch(req)
File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 290, in dispatch
canonical_command=req.canonical_command,
File "/usr/lib64/python2.7/site-packages/mercurial/ui.py", line 1991, in log
logger.log(self, event, msg, opts)
File "/usr/lib64/python2.7/site-packages/hgext/logtoprocess.py", line 72, in log
procutil.runbgcommand(script, fullenv, shell=True)
File "/usr/lib64/python2.7/site-packages/mercurial/utils/procutil.py", line 597, in runbgcommand
b'error running %r: %s' % (cmd, os.strerror(returncode)),
OSError: [Errno 7] error running 'whatever': Argument list too long
This can happen if you pass a bunch of filenames to hg commit, for instance.
This is due to a size limit on individual env vars (on linux, but I
imagine there are similar limits in other OSes):
$ FOO=$(yes | head -c 131000) /usr/bin/true
$ FOO=$(yes | head -c 132000) /usr/bin/true
-bash: /usr/bin/true: Argument list too long
I propose to avoid this by truncating the message. I didn't make the
limit configurable as it doesn't seem particularly convenient to
customize this. I'm not sure if various OSes would want radically
different limits here?
Differential Revision: https://phab.mercurial-scm.org/D8203
Raphaël Gomès <rgomes@octobus.net> [Mon, 24 Feb 2020 17:57:57 +0100] rev 44441
rust-cpython: make `NonNormalEntires` iterable to fix `fsmonitor` (issue6276)
This fixes a bug when using `fsmonitor` that tries to iterate on the non normal
set, by adding a shared iterator interface.
Differential Revision: https://phab.mercurial-scm.org/D8143
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 14:50:39 +0200] rev 44440
hgext: start building a library for simple hooks
Many workflows depend on hooks to enforce certain policies, e.g. to
prevent forced pushes. The Mercurial Guide includes some cases and
Google can help finding others, but it can save users a lot of time
if hg itself has a couple of examples for further customization.
Differential Revision: https://phab.mercurial-scm.org/D6825
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 25 Feb 2020 20:27:39 -0500] rev 44439
exchange: turn on option that makes concurrent pushes work better
The motivation is simply to make hg work better out of the box.
This is a slight backwards compatibility break, because client
extensions could have assumed that the list of heads the client sees
during discovery will be the list of heads during the entirety of the
push. It seems unlikely to matter, and not worth mentioning.
There's a fair amount of diff in tests, but this is just due to
sending a few more bytes on the wire, except for test-acl.t.
The extra "invalid branch cache" lines in test-acl.t don't seem to
indicate a problem: the branchcache now get computed during the bundle
application (because of the check:updated-heads bundle part), but
doesn't get rolled back when transactions rollback, thus causing a
message in the next operation computing the branch cache. Before this
change, I assume the branchcache was only computed on transaction
commit, so not computed at all when the transactions roll back, thus
no messages.
Differential Revision: https://phab.mercurial-scm.org/D8202
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 15:34:51 -0500] rev 44438
update: simplify slightly
Differential Revision: https://phab.mercurial-scm.org/D8204
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 01 Mar 2020 21:16:45 -0500] rev 44437
help: clarify behavior of server.concurrent-push-mode
So it doesn't seemingly say that old clients cannot talk to server
configured with concurrent-push-mode=check-related. They can, they
just don't get the benefit.
Differential Revision: https://phab.mercurial-scm.org/D8201
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:30:18 -0800] rev 44436
commit: error out on unresolved files even if commit would be empty
Differential Revision: https://phab.mercurial-scm.org/D8195
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:49:13 -0800] rev 44435
tests: add test of committing with conflicts but no changes in wdir
I'm about to change the behavior slightly here, so let's have a test
that shows that.
Differential Revision: https://phab.mercurial-scm.org/D8194