- Nov 08, 2020
-
-
sliquister authored
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
-
Gregory Szorc authored
Bug found through pytype. Differential Revision: https://phab.mercurial-scm.org/D9280
-
Gregory Szorc authored
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
-
- Nov 16, 2020
-
-
Raphaël Gomès authored
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
-
Raphaël Gomès authored
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
-
- Nov 17, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9335
-
Martin von Zweigbergk authored
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
-
- Nov 16, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9324
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9323
-
- Nov 13, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9322
-
Martin von Zweigbergk authored
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
-
- Nov 17, 2020
-
-
Martin von Zweigbergk authored
I plan to reuse `formatparse()` in the next patch. Differential Revision: https://phab.mercurial-scm.org/D9331
-
- Nov 16, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9330
-
- Nov 17, 2020
-
-
Yuya Nishihara authored
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.
-
- Nov 12, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9329
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9328
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9327
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9326
-
- Nov 10, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9313
-
- Oct 20, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9312
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9311
-
- Oct 12, 2020
-
-
Martin von Zweigbergk authored
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
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9309
-
- Nov 13, 2020
-
-
Martin von Zweigbergk authored
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
-
- Nov 12, 2020
-
-
Martin von Zweigbergk authored
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
-
- Nov 06, 2020
-
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D9293
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D9292
-
- Nov 11, 2020
-
-
Mathias De Mare authored
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
-
- Sep 01, 2020
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D9291
-
- Nov 10, 2020
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D9290
-
- Nov 03, 2020
-
-
Augie Fackler authored
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
-
- Nov 06, 2020
-
-
Gregory Szorc authored
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
-
- Nov 09, 2020
-
-
Martin von Zweigbergk authored
Without this, the test starts failing with D9273 (the change to `pyexename` to be specific). Differential Revision: https://phab.mercurial-scm.org/D9286
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9242
-
- Oct 07, 2020
-
-
Martin von Zweigbergk authored
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
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
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
-
- Nov 08, 2020
-
-
Martin von Zweigbergk authored
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
-
- Nov 03, 2020
-
-
Martin von Zweigbergk authored
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
-
- Nov 08, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9282
-
- Nov 07, 2020
-
-
Augie Fackler authored
-