- 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 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 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
-
- 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
-
- Jun 23, 2020
-
-
Martin von Zweigbergk authored
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
-
Martin von Zweigbergk authored
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
-
- Oct 20, 2020
-
-
Antoine cezar authored
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
-
- Oct 29, 2020
-
-
Dan Villiom Podlaski Christiansen authored
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
-
- Oct 16, 2020
-
-
Martin von Zweigbergk authored
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
-
Martin von Zweigbergk authored
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
-
Martin von Zweigbergk authored
`--source` is the recommended flag for regular users (`--rev` is available for advanced users). Differential Revision: https://phab.mercurial-scm.org/D9224
-
- Oct 26, 2020
-
-
Dan Villiom Podlaski Christiansen authored
Differential Revision: https://phab.mercurial-scm.org/D9261
-
- Oct 29, 2020
-
-
Antoine cezar authored
Differential Revision: https://phab.mercurial-scm.org/D9264
-
- Oct 13, 2020
-
-
Pierre-Yves David authored
See test documentation for details. This is yet another corner case for copy tracing. Differential Revision: https://phab.mercurial-scm.org/D9200
-
- Oct 29, 2020
-
-
Martin von Zweigbergk authored
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
-
Martin von Zweigbergk authored
-
- Oct 24, 2020
-
-
Matt Harbison authored
I noticed after doing an update from an obsolete revision with a dirty wdir that the obsolete commit stayed visible for no obvious reason. It was decided in 85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in order to allow re-resolving. Since the point of pinning the obsolete parents was to allow resolving in the first place (aaeccdb6e654), it makes sense to also gate it on whether or not there are any remaining files to resolve. This might result in pinning again if files are marked unresolved again, but that seems reasonable, given that it still solves the original issue. Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is likely to cause complaints about pushing multiple heads or other unexpected errors. So the faster it comes out of that state, the better. Differential Revision: https://phab.mercurial-scm.org/D9248
-
- Oct 28, 2020
-
-
Dan Villiom Podlaski Christiansen authored
Differential Revision: https://phab.mercurial-scm.org/D9256
-
- Oct 23, 2020
-
-
Yuya Nishihara authored
I initially thought this is a py3-compat bug of passwordmgr._writedebug(), but actually returning (None, str) pair is wrong at all. HTTP authentication would continue with user="None" in that case. Since registering a password of user=None should also be wrong, this patch simply adds early return.
-
- Oct 29, 2020
-
-
Dan Villiom Podlaski Christiansen authored
I noticed when pulling with hg-git in a repository that already had the changes, but pulled from another Mercurial repository. This meant that hg-git would re-create exact matches of the changesets, and if they were public, they'd get reverted to drafts. Differential Revision: https://phab.mercurial-scm.org/D9253
-
- Oct 13, 2020
-
-
Matt Harbison authored
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
-
- Oct 18, 2020
-
-
Jörg Sonnenberger authored
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
-
- Oct 15, 2020
-
-
Pierre-Yves David authored
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
-
- Jul 01, 2020
-
-
Pulkit Goyal authored
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
-
- Sep 18, 2020
-
-
Pulkit Goyal authored
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
-
Pulkit Goyal authored
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
-
- Oct 14, 2020
-
-
Martin von Zweigbergk authored
I also removed some unnecessary `#if no-changeset` where the `#else` was the same :P Differential Revision: https://phab.mercurial-scm.org/D9204
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
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
-
- Oct 27, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9255
-
Martin von Zweigbergk authored
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
-
Martin von Zweigbergk authored
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
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9251
-
- Oct 26, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9249
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9247
-