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

merge with stable

merge with stable

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

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

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

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

mq: don't tell user to commit merge that we already committed Differential Revision: https://phab.mercurial-scm.org/D8000

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

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

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

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

phabricator: rename a variable to clarify that it is the parent filecontext Differential Revision: https://phab.mercurial-scm.org/D8219

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

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

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

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

phabricator: pass ui instead of repo to `userphids()` Also not a repository operation. Differential Revision: https://phab.mercurial-scm.org/D8207

phabricator: pass ui instead of repo to `querydrev()` Also not a repository operation. Differential Revision: https://phab.mercurial-scm.org/D8206

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

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

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

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

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

update: simplify slightly Differential Revision: https://phab.mercurial-scm.org/D8204

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

commit: error out on unresolved files even if commit would be empty Differential Revision: https://phab.mercurial-scm.org/D8195

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