Thu, 12 Nov 2020 14:07:34 -0800 templates: define a {onelinesummary} keyword
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 14:07:34 -0800] rev 45883
templates: define a {onelinesummary} keyword It is sometimes useful to be able to use the configured `command-template.oneline-summary` in higher-level templates. For example, I would like to use it in an internal template that lists commits in a "review unit" (kind of a pull request). This patch adds support for that. We may want to define a way of formatting a context using a command-specific override (from `command-templates.oneline-summary.<command>`), but that will have to be a template function instead. I don't plan to do that, but I'm mentioning it now in case reviewers would prefer that we use a no-arg function (i.e. `{onelinesummary()}`) already today to prepare for that. Differential Revision: https://phab.mercurial-scm.org/D9314
Fri, 30 Oct 2020 12:46:38 -0700 relnotes: document new [command-templates] section
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Oct 2020 12:46:38 -0700] rev 45882
relnotes: document new [command-templates] section Differential Revision: https://phab.mercurial-scm.org/D9266
Fri, 30 Oct 2020 13:26:18 -0700 help: document the new [command-templates] config section
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Oct 2020 13:26:18 -0700] rev 45881
help: document the new [command-templates] config section Differential Revision: https://phab.mercurial-scm.org/D9265
Sun, 08 Nov 2020 16:23:35 -0500 strip: move into core
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 08 Nov 2020 16:23:35 -0500] rev 45880
strip: move into core As discussed at the 5.2 sprint, replace strip extension by a core command, debugstrip. Obviously, the extension stays for backwards compatibility. As an implementation note, I moved the strip file as is into core, which is not done elsewhere, AFAIK. I could have inlined it into debugcommands, but that doesn't sound great. Differential Revision: https://phab.mercurial-scm.org/D9285
Sat, 07 Nov 2020 16:36:19 -0800 revlog: pass sidedata argument to flagutil.processflagswrite()
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Nov 2020 16:36:19 -0800] rev 45879
revlog: pass sidedata argument to flagutil.processflagswrite() Bug found through pytype. Differential Revision: https://phab.mercurial-scm.org/D9280
Sat, 07 Nov 2020 16:45:58 -0800 pure: guard against empty blocks
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Nov 2020 16:45:58 -0800] rev 45878
pure: guard against empty blocks If blocks is empty, we append `None` to the returned list, which is incorrect. This subtle issue was caught by pytype, which correctly identified the return value as List[Optional[Tuple]] because of this possibility. Differential Revision: https://phab.mercurial-scm.org/D9279
Mon, 16 Nov 2020 16:38:57 +0100 rust-status: don't bubble up os errors, translate them to bad matches
Raphaël Gomès <rgomes@octobus.net> [Mon, 16 Nov 2020 16:38:57 +0100] rev 45877
rust-status: don't bubble up os errors, translate them to bad matches In the rare cases when either the OS/filesystem throws an error on an otherwise valid action, or because a path is not representable on the filesystem, or because of concurrent actions in the filesystem, we want to warn the user about said path instead of bubbling up the error, causing an exception to be raised in the Python layer. Differential Revision: https://phab.mercurial-scm.org/D9320
Mon, 16 Nov 2020 16:36:00 +0100 rust-status: properly translate OSError to Python
Raphaël Gomès <rgomes@octobus.net> [Mon, 16 Nov 2020 16:36:00 +0100] rev 45876
rust-status: properly translate OSError to Python This is probably never going to be called after the next few patches, but we might as well make sure this is done correctly for the future rewrite. Differential Revision: https://phab.mercurial-scm.org/D9319
Mon, 16 Nov 2020 21:28:42 -0800 shelve: clear merge state after partial shelve
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 21:28:42 -0800] rev 45875
shelve: clear merge state after partial shelve Differential Revision: https://phab.mercurial-scm.org/D9335
Mon, 16 Nov 2020 22:38:36 -0800 tests: show that interactive shelve can leave the repo with a merge state
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 22:38:36 -0800] rev 45874
tests: show that interactive shelve can leave the repo with a merge state If part of a file is shelved (as we already do in a test), there will be an unfinished merge state left after `hg shelve` finishes. There should never be a merge conflict and there should never be a reason that the user would like to re-resolve conflicts, so we should clear that state (see next patch). Differential Revision: https://phab.mercurial-scm.org/D9334
Mon, 16 Nov 2020 10:30:53 -0800 histedit: disable color while rendering template for use in plan
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 10:30:53 -0800] rev 45873
histedit: disable color while rendering template for use in plan Differential Revision: https://phab.mercurial-scm.org/D9324
Mon, 16 Nov 2020 10:30:06 -0800 tests: show how `hg histedit` can put color codes in histedit plan
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 10:30:06 -0800] rev 45872
tests: show how `hg histedit` can put color codes in histedit plan Differential Revision: https://phab.mercurial-scm.org/D9323
Fri, 13 Nov 2020 09:41:49 -0800 split: disable color while rendering template for use in commit message
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Nov 2020 09:41:49 -0800] rev 45871
split: disable color while rendering template for use in commit message Differential Revision: https://phab.mercurial-scm.org/D9322
Thu, 12 Nov 2020 17:06:45 -0800 tests: show how `hg split` can put color codes in commit template
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 17:06:45 -0800] rev 45870
tests: show how `hg split` can put color codes in commit template With D9255, I made it so `hg split` respects the `commmand-templates.oneline-summary` config. I don't think I realized that the output I modified was being put in a commit message template. The result was that if you have coloring enabled, you get colors in the commit template. This patch show that. The test is unfortunately pretty verbose (like most other `hg split` tests) and shows a bunch of irrelevant "color codes" (templater labels). Differential Revision: https://phab.mercurial-scm.org/D9321
Mon, 16 Nov 2020 16:00:13 -0800 dispatch: move some helper functions down into scmutil
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 16:00:13 -0800] rev 45869
dispatch: move some helper functions down into scmutil I plan to reuse `formatparse()` in the next patch. Differential Revision: https://phab.mercurial-scm.org/D9331
Mon, 16 Nov 2020 15:11:51 -0800 errors: raise more specific errors from rewriteutil
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 15:11:51 -0800] rev 45868
errors: raise more specific errors from rewriteutil Differential Revision: https://phab.mercurial-scm.org/D9330
Tue, 17 Nov 2020 19:29:08 +0900 chgserver: backport py3 buffered I/O workarounds from procutil
Yuya Nishihara <yuya@tcha.org> [Tue, 17 Nov 2020 19:29:08 +0900] rev 45867
chgserver: backport py3 buffered I/O workarounds from procutil I've recently switched to new machine and I found chg's stdout is fully buffered. Even though chg server is a daemon process, it inherits the environment where the chg client originally forked the server. This means the server's stdout might have been wrapped by LineBufferedWrapper. That's why we need to do wrap/unwrap in both ways. The "if" condition in _restoreio() looks weird, but I'm not willing to clean things up because stdio behavior is fundamentally different between py2 and py3, and py2 support will be dropped anyway.
Thu, 12 Nov 2020 15:28:06 -0800 errors: use InputError for some errors on `hg clone`
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 15:28:06 -0800] rev 45866
errors: use InputError for some errors on `hg clone` Differential Revision: https://phab.mercurial-scm.org/D9329
Thu, 12 Nov 2020 13:22:40 -0800 errors: raise InputError when given non-existent paths etc
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 13:22:40 -0800] rev 45865
errors: raise InputError when given non-existent paths etc Differential Revision: https://phab.mercurial-scm.org/D9328
Thu, 12 Nov 2020 10:35:33 -0800 errors: use InputError for errors about bad label names (tags etc)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 10:35:33 -0800] rev 45864
errors: use InputError for errors about bad label names (tags etc) Differential Revision: https://phab.mercurial-scm.org/D9327
Thu, 12 Nov 2020 09:53:14 -0800 errors: use InputError for errors about bad paths
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 09:53:14 -0800] rev 45863
errors: use InputError for errors about bad paths Differential Revision: https://phab.mercurial-scm.org/D9326
Tue, 10 Nov 2020 09:14:01 -0800 destutil: raise more specific error when histedit.defaultrev is empty
Martin von Zweigbergk <martinvonz@google.com> [Tue, 10 Nov 2020 09:14:01 -0800] rev 45862
destutil: raise more specific error when histedit.defaultrev is empty Differential Revision: https://phab.mercurial-scm.org/D9313
Tue, 20 Oct 2020 08:56:00 -0700 errors: raise more specific errors when default remote not configured
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Oct 2020 08:56:00 -0700] rev 45861
errors: raise more specific errors when default remote not configured Differential Revision: https://phab.mercurial-scm.org/D9312
Thu, 22 Oct 2020 13:56:01 -0700 errors: set detailed exit code to 30 for config errors
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 13:56:01 -0700] rev 45860
errors: set detailed exit code to 30 for config errors This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9311
Mon, 12 Oct 2020 12:44:18 -0700 errors: introduce StateError and use it from commands and cmdutil
Martin von Zweigbergk <martinvonz@google.com> [Mon, 12 Oct 2020 12:44:18 -0700] rev 45859
errors: introduce StateError and use it from commands and cmdutil This very similar to an earlier patch (which was for `InputError`). In this patch, I also updated the transplant extension only because `test-transplant.t` would otherwise have needed a `#if continueflag`. Differential Revision: https://phab.mercurial-scm.org/D9310
Thu, 22 Oct 2020 13:31:34 -0700 errors: set detailed exit code to 100 for some remote errors
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 13:31:34 -0700] rev 45858
errors: set detailed exit code to 100 for some remote errors This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9309
Thu, 12 Nov 2020 21:56:52 -0800 errors: catch urllib errors specifically instead of using safehasattr()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 21:56:52 -0800] rev 45857
errors: catch urllib errors specifically instead of using safehasattr() Before this patch, we would catch `IOError` and `OSError` and check if the instance had a `.code` member (indicates `HTTPError`) or a `.reason` member (indicates the more generic `URLError`). It seems to me that can simply catch those exception specifically instead, so that's what this code does. The existing code is from fbe8834923c5 (commands: report http exceptions nicely, 2005-06-17), so I suspect it's just that there was no `urllib2` (where `URLError` lives) back then. The old code mentioned `SSLError` in a comment. The new code does *not* try to catch that. The documentation for `ssl.SSLError` says that it has a `.reason` property, but `python -c 'import ssl; print(dir(ssl.SSLError("foo", Exception("bar"))))` doesn't mention that property on either Python 2 or Python 3 on my system. It also seems that `sslutil` is pretty careful about converting `ssl.SSLError` to `error.Abort`. It also is carefult to not assume that instances of the exception have a `.reason`. So I at least don't want to catch `ssl.SSLError` and handle it the same way as `URLError` because that would likely result in a crash. I also wonder if we don't need to handle it at all (because `sslutil` might handle all the cases). It's now early in the release cycle, so perhaps we can just see how it goes? Differential Revision: https://phab.mercurial-scm.org/D9318
Thu, 12 Nov 2020 08:29:55 -0800 errors: raise InputError in fancyopts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 08:29:55 -0800] rev 45856
errors: raise InputError in fancyopts If a value of wrong type is passed to a command line flag, that's cleary an InputError. Differential Revision: https://phab.mercurial-scm.org/D9308
Fri, 06 Nov 2020 17:32:23 +0100 packaging: switch centos 7 packaging to python 3
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 06 Nov 2020 17:32:23 +0100] rev 45855
packaging: switch centos 7 packaging to python 3 Differential Revision: https://phab.mercurial-scm.org/D9293
Fri, 06 Nov 2020 11:24:54 +0100 packaging: remove centos5 and centos6 support
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 06 Nov 2020 11:24:54 +0100] rev 45854
packaging: remove centos5 and centos6 support Differential Revision: https://phab.mercurial-scm.org/D9292
Wed, 11 Nov 2020 22:01:45 +0100 test-filecache: use sys.executable to call python
Mathias De Mare <mathias.de_mare@nokia.com> [Wed, 11 Nov 2020 22:01:45 +0100] rev 45853
test-filecache: use sys.executable to call python As was mentioned in c102b704edb5, test scripts calling 'python' or 'python3' might use the wrong python. For test-filecache.py, this causes a failed test on CentOS 7. Differential Revision: https://phab.mercurial-scm.org/D9295
Tue, 01 Sep 2020 11:03:47 -0400 make: add a pyoxidizer target
Augie Fackler <augie@google.com> [Tue, 01 Sep 2020 11:03:47 -0400] rev 45852
make: add a pyoxidizer target Differential Revision: https://phab.mercurial-scm.org/D9291
Tue, 10 Nov 2020 12:44:15 -0500 pyoxidizer: switch to modern config using run_command instead of run_mode
Augie Fackler <augie@google.com> [Tue, 10 Nov 2020 12:44:15 -0500] rev 45851
pyoxidizer: switch to modern config using run_command instead of run_mode Differential Revision: https://phab.mercurial-scm.org/D9290
Tue, 03 Nov 2020 16:25:33 -0500 pyoxidizer: default to one-file binary on non-Windows platforms
Augie Fackler <augie@google.com> [Tue, 03 Nov 2020 16:25:33 -0500] rev 45850
pyoxidizer: default to one-file binary on non-Windows platforms Windows has some extra constraints that require a multi-file install, but we expect folks to use an MSI or similar installer there so it's less of a big deal. Differential Revision: https://phab.mercurial-scm.org/D9289
Fri, 06 Nov 2020 13:58:59 -0800 global: use python3 in shebangs
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Nov 2020 13:58:59 -0800] rev 45849
global: use python3 in shebangs Python 3 is the future. We want Python scripts to be using Python 3 by default. This change updates all `#!/usr/bin/env python` shebangs to use `python3`. Does this mean all scripts use or require Python 3: no. In the test environment, the `PATH` environment variable in tests is updated to guarantee that the Python executable used to run run-tests.py is used. Since test scripts all now use `#!/usr/bin/env python3`, we had to update this code to install a `python3` symlink instead of `python`. It is possible there are some random scripts now executed with the incorrect Python interpreter in some contexts. However, I would argue that this was a pre-existing bug: we should almost always be executing new Python processes using the `sys.executable` from the originating Python script, as `python` or `python3` won't guarantee we'll use the same interpreter. Differential Revision: https://phab.mercurial-scm.org/D9273
Mon, 09 Nov 2020 09:58:44 -0800 tests: use python from environment in test-parseindex2.py
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Nov 2020 09:58:44 -0800] rev 45848
tests: use python from environment in test-parseindex2.py Without this, the test starts failing with D9273 (the change to `pyexename` to be specific). Differential Revision: https://phab.mercurial-scm.org/D9286
Thu, 22 Oct 2020 13:38:14 -0700 errors: set detailed exit code to 20 for locking errors
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 13:38:14 -0700] rev 45847
errors: set detailed exit code to 20 for locking errors This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9242
Tue, 06 Oct 2020 22:36:15 -0700 errors: introduce InputError and use it from commands and cmdutil
Martin von Zweigbergk <martinvonz@google.com> [Tue, 06 Oct 2020 22:36:15 -0700] rev 45846
errors: introduce InputError and use it from commands and cmdutil This patch introduces a `InputError` class and replaces many uses of `error.Abort` by it in `commands` and `cmdutil`. This is a part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. There will later be a different class for state errors (to raise e.g. when there's an unfinished operation). It's not always clear when one should report an input error and when it should be a state error. We can always adjust later if I got something wrong in this patch (but feel free to point out any you notice now). Differential Revision: https://phab.mercurial-scm.org/D9167
Wed, 21 Oct 2020 19:00:16 -0700 errors: add config that lets user get more detailed exit codes
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Oct 2020 19:00:16 -0700] rev 45845
errors: add config that lets user get more detailed exit codes This adds an experimental config that lets the user get more detailed exit codes. For example, there will be a specific error code for input/user errors. This is part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. I've made the config part of tweakdefaults. I've made the config enabled by default in tests. My reasoning is that we want to see that each specific error case gives the right exit code and we don't want to duplicate all error cases in the entire test suite. It also makes it easy to grep the `.t` files for `[255]` to find which cases we have left to fix. The logic for the current exit codes is quite simple, so I'm not too worried about regressions there. I've added a test case specifically for the "legacy" exit codes. I've set the detailed exit status only for the case of `InterventionRequired` and `SystemExit` for now (the cases where we currently return something other than 255), just to show that it works. Differential Revision: https://phab.mercurial-scm.org/D9238
Sat, 07 Nov 2020 21:50:28 -0800 worker: raise exception instead of calling sys.exit() with child's code
Martin von Zweigbergk <martinvonz@google.com> [Sat, 07 Nov 2020 21:50:28 -0800] rev 45844
worker: raise exception instead of calling sys.exit() with child's code When a worker process returns an error code, we would call `sys.exit()` with that exit code on the main process. The `SystemExit` exception would then get caught in `scmutil.callcatch()`, which would return that error code. The comment there says "Commands shouldn't sys.exit directly", which I agree with. This patch changes it so we raise a specific exception when a worker fails so we can catch instead. I think that means that `SystemExit` is now always an internal error. (I had earlier thought that this call to `sys.exit()` was from within the child process until Matt Harbison made me look again, so thanks for that!) Differential Revision: https://phab.mercurial-scm.org/D9287
Tue, 03 Nov 2020 09:56:02 -0800 config: read system hgrc in lexicographical order
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 09:56:02 -0800] rev 45843
config: read system hgrc in lexicographical order This is similar to edbcf5b239f9 (config: read configs from directories in lexicographical order, 2019-04-03). Apparently I forgot to sort the system hgrc files there. That's fixed by this patch. Differential Revision: https://phab.mercurial-scm.org/D9269
Sun, 08 Nov 2020 20:12:32 +0100 relnotes: drop 5.6 release entries from next
Joerg Sonnenberger <joerg@bec.de> [Sun, 08 Nov 2020 20:12:32 +0100] rev 45842
relnotes: drop 5.6 release entries from next Differential Revision: https://phab.mercurial-scm.org/D9282
Sat, 07 Nov 2020 15:02:53 -0500 merge with stable
Augie Fackler <augie@google.com> [Sat, 07 Nov 2020 15:02:53 -0500] rev 45841
merge with stable
Mon, 05 Oct 2020 19:46:31 -0700 makefile: use Python 3 by default (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2020 19:46:31 -0700] rev 45840
makefile: use Python 3 by default (BC) This change is long overdue IMO. .. bc:: Makefile now uses `python3` instead of `python` by default on non-Windows platforms. This means Mercurial will be built and run with Python 3 instead of Python 2.7 by default. To continue using Python 2, set the PYTHON variable. e.g. `make install PYTHON=python2.7`. Differential Revision: https://phab.mercurial-scm.org/D7258
Tue, 03 Nov 2020 20:28:23 -0800 hgweb: don't call sys.exit() in httpservice.run()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:28:23 -0800] rev 45839
hgweb: don't call sys.exit() in httpservice.run() If I'm reading the code correctly, `mercurial.server.createservice()` can return an hgweb service or one of three types of command server services. The caller then calls `mercurial.server.runservice()`, passing it the returned service's run method. Only the hgweb service was calling `sys.exit()`. It has been that way since 8d44649df03b (refactor ssh server., 2006-06-04). That commit message doesn't provide any explanation. Let's clean up and have the code follow the usual return path into the `dispatch` module. After this patch, there should be no remaining places left where we call `sys.exit()` except for valid uses in the `dispatch` and `worker` modules. Differential Revision: https://phab.mercurial-scm.org/D9272
Tue, 03 Nov 2020 20:20:49 -0800 serve: simply return instead of calling sys.exit() in `hg serve --stdio`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:20:49 -0800] rev 45838
serve: simply return instead of calling sys.exit() in `hg serve --stdio` The shouldn't be a reason to call `sys.exit()` instead of letting the code return normally. I've remove the call in both `hg serve` and `hg debugserve`. Differential Revision: https://phab.mercurial-scm.org/D9271
Tue, 03 Nov 2020 20:18:26 -0800 httpservice: move sys.exit() out of serve_forever()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Nov 2020 20:18:26 -0800] rev 45837
httpservice: move sys.exit() out of serve_forever() This is a simple refactoring to show the callers of the method, so it's easier to reason about the impact of removing the `sys.exit()` calls in subsequent patches. Differential Revision: https://phab.mercurial-scm.org/D9270
Mon, 22 Jun 2020 22:47:43 -0700 copies: handle more cases where a file got replaced by a copy
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jun 2020 22:47:43 -0700] rev 45836
copies: handle more cases where a file got replaced by a copy This patch fixes the changeset-centric version in a pretty straight-forward way. It fixes it to automatically resolve the conflict, which is better than resulting in a modify/delete conflict as it was before b4057d001760 (merge: when rename was made on both sides, use ancestor as merge base, 2020-01-22). I'll leave it for later to test and explicitly handle cases where files have been renamed to the same target on different sides of the merge. Differential Revision: https://phab.mercurial-scm.org/D8653
Mon, 22 Jun 2020 22:47:33 -0700 tests: test more cases where a file got replaced by a copy
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jun 2020 22:47:33 -0700] rev 45835
tests: test more cases where a file got replaced by a copy This adds a test where a file is modified on one branch and is renamed onto another file in another branch. That should ideally be automatically resolved (by propagating the modification to the rename destination). Alternatively, it could be considered a modify/delete conflict. It should at least not be automatically resolved by ignoring the modification. However, that is what actually happens with the changeset-centric algorithm since I broke it in b4057d001760 (merge: when rename was made on both sides, use ancestor as merge base, 2020-01-22). Before that commit, it resulted in a modify/delete conflict. The filelog-centric algorithm was broken already before that commit. Differential Revision: https://phab.mercurial-scm.org/D8652
Wed, 07 Oct 2020 03:00:26 +0200 unionrepo: don't insert index tuples with None as int field
Joerg Sonnenberger <joerg@bec.de> [Wed, 07 Oct 2020 03:00:26 +0200] rev 45834
unionrepo: don't insert index tuples with None as int field None is not a valid size. Use -1 as placeholder instead. This will be necessary when the index starts enforcing type correctness. Differential Revision: https://phab.mercurial-scm.org/D9161
Wed, 07 Oct 2020 03:00:01 +0200 bundlerepo: don't insert index tuples with full nodes as linkrev
Joerg Sonnenberger <joerg@bec.de> [Wed, 07 Oct 2020 03:00:01 +0200] rev 45833
bundlerepo: don't insert index tuples with full nodes as linkrev The index format has a documented format and latter changes will start to enforce the field types. The bundlerepo uses full nodes for the linkrev field when it should be using revision numbers. Use the link mapping to resolve them, except in the special case of self-references. Those are actually indications of a missing linkrev. Differential Revision: https://phab.mercurial-scm.org/D9160
Tue, 20 Oct 2020 15:09:08 +0200 rhg: add full node id support for `debugdata` command
Antoine cezar<acezar@chwitlabs.fr> [Tue, 20 Oct 2020 15:09:08 +0200] rev 45832
rhg: add full node id support for `debugdata` command Unlike other later implemented commands `debugdata` only supported revision number. This changeset add full node id support for consistency with other commands. Differential Revision: https://phab.mercurial-scm.org/D9230
Thu, 29 Oct 2020 13:54:25 +0100 commit: warn the user when a commit already exists
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Thu, 29 Oct 2020 13:54:25 +0100] rev 45831
commit: warn the user when a commit already exists Sometimes, a commit will result in an exact match of a preexisting commit, and if that commit isn't a branch head, hg will incorrectly note that it created a new head. Instead, we should warn the user that commit already existed in the repository. In practice, this bug is rather uncommon, and will only occur when the usr explicitly sets the date. Please note that this commit contains an API change to cmdutil.commitstatus() Differential Revision: https://phab.mercurial-scm.org/D9257
Tue, 06 Oct 2020 13:34:51 +0200 revlog: don't cache parsed tuples in the C module
Joerg Sonnenberger <joerg@bec.de> [Tue, 06 Oct 2020 13:34:51 +0200] rev 45830
revlog: don't cache parsed tuples in the C module A cached entry creates ~8 Python objects per cached changeset, which comes to around 200 Bytes per cached changeset on AMD64. Especially for operations that touch a lot of changesets, that can easily sum up to more than a 100MB of memory. Simple tests on large repositories show <2% runtime penalty for ripping out the cache, even for cache heavy operations like "hg log" for all revisions. Differential Revision: https://phab.mercurial-scm.org/D9155
Fri, 16 Oct 2020 16:00:32 -0700 fix: only check for obsolete commits in the --rev case
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 16:00:32 -0700] rev 45829
fix: only check for obsolete commits in the --rev case With both `--all` and `--source`, we already exclude obsolete revisions in the revset, so there's no need to call `checkfixablectx()` in those cases. Differential Revision: https://phab.mercurial-scm.org/D9227
Fri, 16 Oct 2020 15:02:46 -0700 fix: don't include obsolete descendants with -s
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 15:02:46 -0700] rev 45828
fix: don't include obsolete descendants with -s The `-s/--source` option is for regular users (`-r` is there for power users). If there are obsolete commits that are descendants of the given revision(s), then they almost definitely should just be left alone. That's what `hg rebase` does as well. So this patch makes it so we skip obsolete commits (including those in the input set itself). Differential Revision: https://phab.mercurial-scm.org/D9226
Fri, 16 Oct 2020 11:15:00 -0700 tests: add test showing how `hg fix -s` deals with obsolete and orphan nodes
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 11:15:00 -0700] rev 45827
tests: add test showing how `hg fix -s` deals with obsolete and orphan nodes We didn't have any tests for how `hg fix -s` behaves with obsolete commits among the descendants. The next patch will change the behavior in this area. Differential Revision: https://phab.mercurial-scm.org/D9225
Fri, 16 Oct 2020 15:05:43 -0700 fix: suggest --source instead of --rev on empty revset
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Oct 2020 15:05:43 -0700] rev 45826
fix: suggest --source instead of --rev on empty revset `--source` is the recommended flag for regular users (`--rev` is available for advanced users). Differential Revision: https://phab.mercurial-scm.org/D9224
Mon, 28 Sep 2020 17:13:15 +0200 hg-core: fix path encoding usage
Antoine cezar<acezar@chwitlabs.fr> [Mon, 28 Sep 2020 17:13:15 +0200] rev 45825
hg-core: fix path encoding usage 1. Hash encoded path are in `.hg/store/dh` instead of `.hg/store/data`. 2. Path encoded index and data files may not have the same parent path. It is not just about replacing `.i` by `.d` Differential Revision: https://phab.mercurial-scm.org/D9121
Mon, 26 Oct 2020 11:45:32 +0100 push: add --all-bookmarks option
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Mon, 26 Oct 2020 11:45:32 +0100] rev 45824
push: add --all-bookmarks option Differential Revision: https://phab.mercurial-scm.org/D9261
Thu, 29 Oct 2020 19:25:33 +0100 rhg: strip copied files metadata from `cat` output
Antoine cezar<acezar@chwitlabs.fr> [Thu, 29 Oct 2020 19:25:33 +0100] rev 45823
rhg: strip copied files metadata from `cat` output Differential Revision: https://phab.mercurial-scm.org/D9264
Mon, 02 Nov 2020 14:39:43 -0500 merge with stable
Augie Fackler <augie@google.com> [Mon, 02 Nov 2020 14:39:43 -0500] rev 45822
merge with stable
Tue, 13 Oct 2020 05:15:44 +0200 copies: make sure deleted copy info do not overwriting unrelated ones
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Oct 2020 05:15:44 +0200] rev 45821
copies: make sure deleted copy info do not overwriting unrelated ones See test documentation for details. This is yet another corner case for copy tracing. Differential Revision: https://phab.mercurial-scm.org/D9200
Wed, 21 Oct 2020 22:30:42 +0200 utils: helper function to print top memory allocation site
Joerg Sonnenberger <joerg@bec.de> [Wed, 21 Oct 2020 22:30:42 +0200] rev 45820
utils: helper function to print top memory allocation site The memorytop function uses Python's tracemalloc module to show the source lines / backtraces with the largest remaining allocations. This allows identifying the origins of active memory by placing calls in strategic locations. Allocations from C extensions will show up as long as they are using the Python allocators. Differential Revision: https://phab.mercurial-scm.org/D9236
Thu, 29 Oct 2020 09:03:08 -0700 templates: include all non-branch namespaces in default one-line summary
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Oct 2020 09:03:08 -0700] rev 45819
templates: include all non-branch namespaces in default one-line summary I left out branches and custom namespaces on purpose from D9252 because I figured that people like us (Google) who have custom namespaces can also have custom configs. However, I just realized that this makes everyone with the topic extension lose the topic they've had in rebase output for a long time (ever since someone was nice enough to add it in D741). Sorry about the churn. The more generic template couldn't easily keep the "log.bookmark" label in the template because the namespace is called "bookmarks" (plural). That means that we can't be compatible with users' existing configs for "log.bookmark", so I decided to change the labels to be in a brand-new "oneline-summary" namespace. Differential Revision: https://phab.mercurial-scm.org/D9262
Thu, 29 Oct 2020 13:29:05 +0100 relnotes: mention improved memory use and underlaying API changes
Joerg Sonnenberger <joerg@bec.de> [Thu, 29 Oct 2020 13:29:05 +0100] rev 45818
relnotes: mention improved memory use and underlaying API changes Differential Revision: https://phab.mercurial-scm.org/D9258
Thu, 29 Oct 2020 00:17:12 -0700 branching: merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Oct 2020 00:17:12 -0700] rev 45817
branching: merge with stable
Sat, 17 Oct 2020 21:57:21 +0900 help: update command synopsis to clarify "cp --forget" only takes destinations
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Oct 2020 21:57:21 +0900] rev 45816
help: update command synopsis to clarify "cp --forget" only takes destinations I'm a bit confused while reading 03690079d7dd, which says "a destination file", but the code loops over matched files.
Tue, 13 Oct 2020 14:16:21 -0400 rebase: update commit hash references in the new commits
Matt Harbison <matt_harbison@yahoo.com> [Tue, 13 Oct 2020 14:16:21 -0400] rev 45815
rebase: update commit hash references in the new commits This excludes the --collapse case because degenerating to p1 is almost certainly as wrong as leaving the old hashes in place. I expect most people to amend the message explicitly when using that. Differential Revision: https://phab.mercurial-scm.org/D9229
Thu, 22 Oct 2020 23:35:04 -0700 histedit: drop fallback to empty string from rendertemplate()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 23:35:04 -0700] rev 45814
histedit: drop fallback to empty string from rendertemplate() AFAICT, `cmdutil.rendertemplate()` always returns bytes (never e.g. `None`), so we don't need to fall back to empty (byte-)string. The fallback has been there since the code was added in 11c076786d56 (histedit: add templating support to histedit's rule file generation, 2019-01-29). Differential Revision: https://phab.mercurial-scm.org/D9244
Tue, 20 Oct 2020 17:32:45 +0200 phases: convert registernew users to use revision sets
Joerg Sonnenberger <joerg@bec.de> [Tue, 20 Oct 2020 17:32:45 +0200] rev 45813
phases: convert registernew users to use revision sets Differential Revision: https://phab.mercurial-scm.org/D9233
Mon, 19 Oct 2020 02:54:12 +0200 phases: allow registration and boundary advancement with revision sets
Joerg Sonnenberger <joerg@bec.de> [Mon, 19 Oct 2020 02:54:12 +0200] rev 45812
phases: allow registration and boundary advancement with revision sets The core internals either use revision sets already or can trivially use them. Use the new interface in cg1unpacker.apply to avoid materializing the list of all new nodes as it is normally just a revision range. This avoids about 67 Bytes / changeset on AMD64 in peak RSS. Differential Revision: https://phab.mercurial-scm.org/D9232
Sun, 18 Oct 2020 22:18:02 +0200 revlog: extend addgroup() with callback for duplicates
Joerg Sonnenberger <joerg@bec.de> [Sun, 18 Oct 2020 22:18:02 +0200] rev 45811
revlog: extend addgroup() with callback for duplicates The addgroup() interface currently doesn't allow the caller to keep track of duplicated nodes except by looking at the returned node list. Add an optional second callback for this purpose and change the return type to a boolean. This allows follow-up changes to use more efficient storage for the node list in places that are memory-sensitive. Differential Revision: https://phab.mercurial-scm.org/D9231
Wed, 07 Oct 2020 14:26:47 +0530 tags: add safety check for len(record) while reading hgtagsfnodescache
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 07 Oct 2020 14:26:47 +0530] rev 45810
tags: add safety check for len(record) while reading hgtagsfnodescache I am trying to fix a breakage where somehow we end up getting a node of 12 length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems highly unlikely that it can happen unless one of `mctx.readfast().get()` or `ctx.filenode()` is returning a node of 12 length. For safety, I think it's better to add a check to make sure that record which we are parsing is of same length we are expecting otherwise we consider that as invalid record. Differential Revision: https://phab.mercurial-scm.org/D9169
Wed, 14 Oct 2020 17:52:18 +0200 procutil: allow to specify arbitrary stdin bytes to runbgcommand
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:52:18 +0200] rev 45809
procutil: allow to specify arbitrary stdin bytes to runbgcommand For automatic clonebundles generation I need to pass arbitrary large amount of data to the process (eg: common nodes, target nodes). I am updating the `runbgcommand` to allow for this. Previously not stdin input was possible, now, one can provide raw bytes and they will be feed to the command through an unnamed temporary files. Differential Revision: https://phab.mercurial-scm.org/D9212
Wed, 14 Oct 2020 17:46:28 +0200 clonebundle: move the manifest filename to a constant
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:46:28 +0200] rev 45808
clonebundle: move the manifest filename to a constant I am about to add more reference to it, so I would rather have it an explicit constant. This allow to unify various call too. Differential Revision: https://phab.mercurial-scm.org/D9209
Thu, 15 Oct 2020 15:57:36 +0200 clonebundles: move a bundle of clone bundle related code to a new module
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Oct 2020 15:57:36 +0200] rev 45807
clonebundles: move a bundle of clone bundle related code to a new module In the process on general clone bundle automatically, we need to make some function available more widely. This is a good opportunity to extract a significant amount of code from `mercurial.exchange` into a new `mercurial.bundlecaches`. This make `mercurial.exchange` move under the 3K line range (hooray…). The module is called `bundlecaches` because I expect it to be eventually useful for more than just clone bundle (like pull bunbles). Differential Revision: https://phab.mercurial-scm.org/D9208
Wed, 01 Jul 2020 15:14:59 +0530 config: add a .hg/hgrc-not-shared which won't be shared in share-safe mode
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 01 Jul 2020 15:14:59 +0530] rev 45806
config: add a .hg/hgrc-not-shared which won't be shared in share-safe mode Previous patches add a safe mode for sharing repositories which involve sharing of source requirements and config files. In certain situations we might need to add a config to source repository which we does not want to share. For this, we add a `.hg/hgrc-not-shared` which won't be shared. This also adds a `--non-shared` flag to `hg config` command to see the non-shared config. Differential Revision: https://phab.mercurial-scm.org/D8673
Fri, 18 Sep 2020 18:52:38 +0530 dispatch: load shared source repository config in share-safe mode
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 18 Sep 2020 18:52:38 +0530] rev 45805
dispatch: load shared source repository config in share-safe mode It seems to me now that there are two steps when config is loaded: 1) on dispatch 2) repository object creation Recent patches added functionality that there can be shares in share-safe mode where config of the source repository is shared with the the shares. However we missed adding logic to read the source config on dispatch. This leads to extensions not being loaded on dispatch and hence extensions command not being recognized. This patch fixes it by reading the shared source config on dispatch. Differential Revision: https://phab.mercurial-scm.org/D9047
Fri, 18 Sep 2020 17:28:22 +0530 tests: add test showing broken extension loading in case of share-safe
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 18 Sep 2020 17:28:22 +0530] rev 45804
tests: add test showing broken extension loading in case of share-safe When we are using share-safe and loading source repository config, we are still not loading the extensions which are enabled in the source repository. This patch demonstrates the bug. Meanwhile it also shows how unreliable `hg debugextensions` is. Differential Revision: https://phab.mercurial-scm.org/D9046
Fri, 09 Oct 2020 10:33:19 +0200 dirstate-tree: simplify the control flow in the Node.insert method
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Oct 2020 10:33:19 +0200] rev 45803
dirstate-tree: simplify the control flow in the Node.insert method But explicitly with the special case early, laying out the various case become simpler. (The initial motivation was to make some future lifetime error simpler). Differential Revision: https://phab.mercurial-scm.org/D9203
Wed, 21 Oct 2020 01:48:09 +0200 revlog: use LRU for the chain cache
Joerg Sonnenberger <joerg@bec.de> [Wed, 21 Oct 2020 01:48:09 +0200] rev 45802
revlog: use LRU for the chain cache For a large repository, this reduces the number of filelog instances and associated data a lot. For a 1% speed penalty, it reduces peak RSS by 20% for the full NetBSD test repository. Differential Revision: https://phab.mercurial-scm.org/D9235
Wed, 14 Oct 2020 08:38:58 -0700 tests: add notes about broken `hg log --follow <file>` with copies in extras
Martin von Zweigbergk <martinvonz@google.com> [Wed, 14 Oct 2020 08:38:58 -0700] rev 45801
tests: add notes about broken `hg log --follow <file>` with copies in extras I also removed some unnecessary `#if no-changeset` where the `#else` was the same :P Differential Revision: https://phab.mercurial-scm.org/D9204
Thu, 22 Oct 2020 10:57:11 -0700 config: move message about leading spaces in config to config.py
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 10:57:11 -0700] rev 45800
config: move message about leading spaces in config to config.py When the config parser raises a ParseError, it uses the line that failed to parse as the error message. It doesn't currently tell the user anything about why it failed to parse. b13b99d39a46 (config: highlight parse error caused by leading spaces (issue3214), 2014-03-16) added a checked based on the error *message* having leading spaces. That has worked fine because only the config parser uses the line itself as error message (I think the revset and fileset parsers use more user-friendly proper messages). It still feels like a hack. Let's make the config parser give a useful message about leading whitespace instead. We should ideally follow up with more useful messages for other parse errors in config files. Differential Revision: https://phab.mercurial-scm.org/D9241
Thu, 22 Oct 2020 09:58:05 -0700 errors: name arguments to ParseError constructor
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 09:58:05 -0700] rev 45799
errors: name arguments to ParseError constructor As with similar previous patches, this is to improve readability. Differential Revision: https://phab.mercurial-scm.org/D9240
Tue, 20 Oct 2020 08:58:20 -0700 errors: remove unnecessary override of __bytes__ in RevlogError
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Oct 2020 08:58:20 -0700] rev 45798
errors: remove unnecessary override of __bytes__ in RevlogError StorageError already provides the same definition. Differential Revision: https://phab.mercurial-scm.org/D9234
Thu, 15 Oct 2020 22:23:02 -0700 commit: leverage cmdutil.check_incompatible_arguments()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Oct 2020 22:23:02 -0700] rev 45797
commit: leverage cmdutil.check_incompatible_arguments() Differential Revision: https://phab.mercurial-scm.org/D9218
Tue, 27 Oct 2020 10:06:17 -0700 split: use default one-line summary
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Oct 2020 10:06:17 -0700] rev 45796
split: use default one-line summary Differential Revision: https://phab.mercurial-scm.org/D9255
Tue, 27 Oct 2020 10:22:36 -0700 phabsend: use default one-line summary
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Oct 2020 10:22:36 -0700] rev 45795
phabsend: use default one-line summary This means that the `phabricator.node` and `phabricator.desc` color configs will no longer be respected, but `log.changeset` and `log.desc` will be respected instead. Differential Revision: https://phab.mercurial-scm.org/D9254
Tue, 27 Oct 2020 15:33:15 -0700 rebase: change and standarize template for rebase's one-line summary
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Oct 2020 15:33:15 -0700] rev 45794
rebase: change and standarize template for rebase's one-line summary This removes the default template in rebase and switches to a centrally defined template. I've simplified it a bit to avoid the conditional parenthesis. I've also added labels so the different parts can be easily colored. The template is somewhat similar to what we've used internally at Google for a few years. I'm happy to change the template if others have opinions. Should we reuse the `color.log.` names as I have? Differential Revision: https://phab.mercurial-scm.org/D9252
Thu, 22 Oct 2020 23:10:06 -0700 rebase: make summary template configurable, with default to shared template
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 23:10:06 -0700] rev 45793
rebase: make summary template configurable, with default to shared template Differential Revision: https://phab.mercurial-scm.org/D9251
Thu, 22 Oct 2020 22:29:22 -0700 rebase: use hard-coded template for one-line commit description
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 22:29:22 -0700] rev 45792
rebase: use hard-coded template for one-line commit description This is to prepare for making making the one-line summary customizable. The template ended up pretty complicated because of the conditional output of "(<bookmarks etc>)". Maybe we can simplify the template later. Differential Revision: https://phab.mercurial-scm.org/D9250
Mon, 26 Oct 2020 10:33:32 -0700 config: move ui.pre-merge-tool-output-template into [command-templates]
Martin von Zweigbergk <martinvonz@google.com> [Mon, 26 Oct 2020 10:33:32 -0700] rev 45791
config: move ui.pre-merge-tool-output-template into [command-templates] Differential Revision: https://phab.mercurial-scm.org/D9249
Fri, 23 Oct 2020 15:59:32 -0700 config: rename ui.mergemarkertemplate to command-templates.mergemarker
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Oct 2020 15:59:32 -0700] rev 45790
config: rename ui.mergemarkertemplate to command-templates.mergemarker Differential Revision: https://phab.mercurial-scm.org/D9247
Fri, 23 Oct 2020 15:27:33 -0700 config: rename ui.graphnodetemplate to command-templates.graphnode
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Oct 2020 15:27:33 -0700] rev 45789
config: rename ui.graphnodetemplate to command-templates.graphnode Differential Revision: https://phab.mercurial-scm.org/D9246
Fri, 23 Oct 2020 10:56:18 -0700 config: add a new [command-templates] section for templates defined by hg
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Oct 2020 10:56:18 -0700] rev 45788
config: add a new [command-templates] section for templates defined by hg The existing `[templates]` section lets the user define their own keys and then refer to them on the command line with `-T`. There are many cases where hg wants to use a user-defined template with a given name, such as `ui.logtemplate` and `ui.mergemarkertemplate`. This patch starts moving such configs in a common section by moving `ui.logtemplate` to `command-templates.log` (with an alias from the old name, of course). Differential Revision: https://phab.mercurial-scm.org/D9245
Mon, 26 Oct 2020 10:08:22 -0700 branching: merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 26 Oct 2020 10:08:22 -0700] rev 45787
branching: merge with stable
Thu, 24 Dec 2020 15:58:08 +0900 log: update documentation about --follow with/without --rev (issue6459) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 24 Dec 2020 15:58:08 +0900] rev 45786
log: update documentation about --follow with/without --rev (issue6459)
Thu, 03 Dec 2020 22:49:01 +0100 bugzilla: pass the url to xmlrpclib.ServerProxy as str stable
Mads Kiilerich <mads@kiilerich.com> [Thu, 03 Dec 2020 22:49:01 +0100] rev 45785
bugzilla: pass the url to xmlrpclib.ServerProxy as str
Thu, 03 Dec 2020 22:49:01 +0100 bugzilla: fix reporting of exceptions with py3 stable
Mads Kiilerich <mads@kiilerich.com> [Thu, 03 Dec 2020 22:49:01 +0100] rev 45784
bugzilla: fix reporting of exceptions with py3
Thu, 03 Dec 2020 18:42:23 +0900 ui: remove excessive strtolocal() from debuguigetpass stable
Yuya Nishihara <yuya@tcha.org> [Thu, 03 Dec 2020 18:42:23 +0900] rev 45783
ui: remove excessive strtolocal() from debuguigetpass ui.getpass() returns Optional[bytes], and strtolocal(bytes) would crash. Follows up 07b0a687c01a "ui: ensure `getpass()` returns bytes."
Thu, 03 Dec 2020 13:36:24 -0500 Added signature for changeset 1d5189a57405 stable
Augie Fackler <raf@durin42.com> [Thu, 03 Dec 2020 13:36:24 -0500] rev 45782
Added signature for changeset 1d5189a57405
Thu, 03 Dec 2020 13:36:23 -0500 Added tag 5.6.1 for changeset 1d5189a57405 stable
Augie Fackler <raf@durin42.com> [Thu, 03 Dec 2020 13:36:23 -0500] rev 45781
Added tag 5.6.1 for changeset 1d5189a57405
Wed, 02 Dec 2020 15:39:01 -0800 rebase: clear merge state when aborting in-memory merge on dirty working copy stable 5.6.1
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:39:01 -0800] rev 45780
rebase: clear merge state when aborting in-memory merge on dirty working copy Differential Revision: https://phab.mercurial-scm.org/D9509
Wed, 02 Dec 2020 15:15:16 -0800 tests: show that in-memory rebase leaves state when working copy is dirty stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:15:16 -0800] rev 45779
tests: show that in-memory rebase leaves state when working copy is dirty When in-memory rebase falls back to on-disk rebase, it checks if the working copy is dirty. If it is, it aborts the rebase. However, it leaves the rebase state on disk. I broke it in feffeb18d412 (rebase: teach in-memory rebase to not restart with on-disk rebase on conflict, 2020-09-18). Differential Revision: https://phab.mercurial-scm.org/D9508
Fri, 27 Nov 2020 14:54:37 -0500 extensions: avoid a crash when the version isn't properly byteified on py3 stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 14:54:37 -0500] rev 45778
extensions: avoid a crash when the version isn't properly byteified on py3 We already force bytestr on the `testedwith` and `buglink` attributes in dispatch.py when generating a bug report with a similar comment about not every extension being ported to py3. We should do the same here, so the function can be properly typed. Differential Revision: https://phab.mercurial-scm.org/D9433
Mon, 23 Nov 2020 11:47:06 -0500 ui: ensure `getpass()` returns bytes stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 23 Nov 2020 11:47:06 -0500] rev 45777
ui: ensure `getpass()` returns bytes Previously, this could return either bytes or str. I'm not sure which direction we should go in, but since the input is bytes, I guess bytes makes sense as output. `debuguigetpass` crashed because it assumed bytes would be returned, `sslcontext.load_cert_chain()` is happy with bytes or str if the type info in PyCharm is correct, and `smtplib.SMTP.login()` wants str. I couldn't figure out how to test this, because the test stalls for input with `echo test | hg debuguigetpass --config ui.interactive=1`, likely because it drains stdin before prompting. The custom input reading with `ui.nontty=1` does not. I'm also a bit concerned with all of this encoding/decoding. The existing code in the mail module uses `encoding.strfromlocal()`, but the username and password are ascii encoded/decoded in `mercurial.url.passwordmgr.find_user_password()` with `pycompat.{str,bytes}url()`. I'm not sure if this inconsistency could cause subtle compatability issues. Differential Revision: https://phab.mercurial-scm.org/D9375
Thu, 26 Nov 2020 02:28:42 -0500 packaging: regenerate the Windows requirements manifest on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 02:28:42 -0500] rev 45776
packaging: regenerate the Windows requirements manifest on Windows SecretStorage is a Linux package, and the other stuff removed is a dependency of it. I assume this was last generated on Linux, and noticed this trying to add another package and regenerating on Windows. Differential Revision: https://phab.mercurial-scm.org/D9404
Thu, 26 Nov 2020 03:09:56 -0500 pyoxidizer: point to the py3 requirements instead of py2 on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 03:09:56 -0500] rev 45775
pyoxidizer: point to the py3 requirements instead of py2 on Windows Differential Revision: https://phab.mercurial-scm.org/D9406
Sat, 21 Nov 2020 16:55:07 -0500 extensions: gracefully warn when doing min version check with no local version stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 16:55:07 -0500] rev 45774
extensions: gracefully warn when doing min version check with no local version After doing a `make clean`, I started getting cryptic failures to import extensions with the `minimumhgversion` attribute on py3: *** failed to import extension evolve: '>' not supported between instances of 'int' and 'NoneType' *** failed to import extension topic: '>' not supported between instances of 'int' and 'NoneType' This now handles the `(None, None)` tuple before comparing, and disables the extension with the same friendly message as in py2. Differential Revision: https://phab.mercurial-scm.org/D9363
Sat, 28 Nov 2020 11:15:54 +0900 diff: do not concatenate immutable bytes while building a/b bodies (issue6445) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 28 Nov 2020 11:15:54 +0900] rev 45773
diff: do not concatenate immutable bytes while building a/b bodies (issue6445) Use bytearray instead. I don't know what's changed since Python 2, but bytes concatenation is 100x slow on Python 3. % python2.7 -m timeit -s "s = b''" "for i in range(10000): s += b'line'" 1000 loops, best of 3: 321 usec per loop % python3.9 -m timeit -s "s = b''" "for i in range(10000): s += b'line'" 5 loops, best of 5: 39.2 msec per loop Benchmark using tailwind.css (measuring the fast path, a is empty): % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 1.580 secs (user 1.560+0.000 sys 0.020+0.000) (this) time: real 1.610 secs (user 1.570+0.000 sys 0.030+0.000) % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 114.500 secs (user 114.460+0.000 sys 0.030+0.000) (this) time: real 2.180 secs (user 2.140+0.000 sys 0.040+0.000) Benchmark using random tabular text data (not the fast path): % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf % hg ci -ma % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf % hg ci -mb % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 3.240 secs (user 3.040+0.000 sys 0.200+0.000 (this) time: real 3.230 secs (user 3.070+0.000 sys 0.160+0.000) % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 44.130 secs (user 43.850+0.000 sys 0.270+0.000) (this) time: real 4.170 secs (user 3.850+0.000 sys 0.310+0.000)
Tue, 01 Dec 2020 01:18:21 -0500 procutil: use rapply(tonativestr, ...) to preserve lists when they come in stable
Augie Fackler <augie@google.com> [Tue, 01 Dec 2020 01:18:21 -0500] rev 45772
procutil: use rapply(tonativestr, ...) to preserve lists when they come in This was broken when script was a list instead of a string. I caught this with an internal extension at Google, and I'm not really sure why it wasn't caught in any kind of CI. Differential Revision: https://phab.mercurial-scm.org/D9471
Tue, 03 Nov 2020 11:24:21 +0900 chg: reset errno prior to calling strtol() stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:24:21 +0900] rev 45771
chg: reset errno prior to calling strtol() Otherwise we can't figure out if the last strtol() invocation failed or not.
Tue, 03 Nov 2020 11:15:50 +0900 chg: do not close dir fd while iterating stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:15:50 +0900] rev 45770
chg: do not close dir fd while iterating It works so long as the dp is the last entry, but readdir(dp) would fail with EBADF. Let's not do that and close the dir fd explicitly.
Tue, 03 Nov 2020 11:12:25 +0900 chg: show debug message for each fd to be closed stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:12:25 +0900] rev 45769
chg: show debug message for each fd to be closed It helps debugging. The number of file descriptors should be small in most cases, so the console output wouldn't get bloated even with CHG_DEBUG=1.
Tue, 03 Nov 2020 11:06:15 +0900 chg: apply clang-format stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:06:15 +0900] rev 45768
chg: apply clang-format
Mon, 02 Nov 2020 11:58:34 +0100 chg: close file descriptors when starting the daemon stable
Mathias De Mare <mathias.de_mare@nokia.com> [Mon, 02 Nov 2020 11:58:34 +0100] rev 45767
chg: close file descriptors when starting the daemon It's good practice to close file descriptors when forking to start a daemon. This did not appear to happen yet, which results in flock hanging in one location in our system (because the chg daemon keeps the locked file open). Differential Revision: https://phab.mercurial-scm.org/D9268
Sat, 31 Oct 2020 17:42:31 -0400 crecord: render chunkpad on Windows (issue6427) stable
Barret Rennie <barret@brennie.ca> [Sat, 31 Oct 2020 17:42:31 -0400] rev 45766
crecord: render chunkpad on Windows (issue6427) When using Windows wrappers of PDCurses (e.g., windows-curses), the chunkpad does not render when executing `hg commit -i`. This is due to attempting to refresh one too many columns of the pad. Differential Revision: https://phab.mercurial-scm.org/D9267
Mon, 02 Nov 2020 14:26:19 -0500 Added signature for changeset 18c17d63fdab stable
Augie Fackler <raf@durin42.com> [Mon, 02 Nov 2020 14:26:19 -0500] rev 45765
Added signature for changeset 18c17d63fdab
Mon, 02 Nov 2020 14:26:18 -0500 Added tag 5.6 for changeset 18c17d63fdab stable
Augie Fackler <raf@durin42.com> [Mon, 02 Nov 2020 14:26:18 -0500] rev 45764
Added tag 5.6 for changeset 18c17d63fdab
(0) -30000 -10000 -3000 -1000 -120 +120 +1000 +3000 tip