Sat, 03 Aug 2019 12:14:34 +0530 config: remove pycompat.bytestr() for defaultvalue
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 03 Aug 2019 12:14:34 +0530] rev 42705
config: remove pycompat.bytestr() for defaultvalue This is a follow-up patch to 51a2e3102db2. This removes `pycompat.bytestr` to preserve `None` in `commands.config()`. Differential Revision: https://phab.mercurial-scm.org/D6712
Sat, 27 Jul 2019 12:19:51 +0530 unshelve: clear shelvedstate and _finishunshelve() on partial unshelve
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 27 Jul 2019 12:19:51 +0530] rev 42704
unshelve: clear shelvedstate and _finishunshelve() on partial unshelve On a partial unshelve, `shelvedstate` was not cleared and `_finishunshelve()` was not called. Ideally, these should be called on this case. This patch makes `shelvedstate` to delete after a successful partial unshelve and calls `_finishunshelve()` in the same case. Differential Revision: https://phab.mercurial-scm.org/D6708
Thu, 25 Jul 2019 22:01:15 +0530 unshelve: delete shelvedstate after a successful unshelve --continue
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 25 Jul 2019 22:01:15 +0530] rev 42703
unshelve: delete shelvedstate after a successful unshelve --continue `unshelve --continue` was preventing the deletion of `shelvedstate` on a partial `unshelve`. Ideally, `shelvedstate` should be deleted after a successful `unshelve`. Now, the behavior of `unshelve --continue` will be as follows in interactive mode: 1] The user tried to `unshelve` changes interactively but, ran into conflicts. 2] They resolved the conflicts and triggered `unshelve --continue` but, unshelved changes partially. 3] Now, on trying to do `unshelve --continue` again will abort as the last `unshelve` was successful and we are deleting the `shelvedstate`. 4] If they want to unshelve the remaining shelved change, they need to trigger `unshelve` without `--continue`. Differential Revision: https://phab.mercurial-scm.org/D6694
Wed, 24 Jul 2019 18:15:27 +0530 unshelve: handle stripping changesets on interactive mode
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:15:27 +0530] rev 42702
unshelve: handle stripping changesets on interactive mode On interactive mode, changesets on `nodestoremove` should be stripped regardless of the shelve is partial or not. This patch modifies `unshelvecontinue()` to do that. Differential Revision: https://phab.mercurial-scm.org/D6686
Tue, 06 Aug 2019 14:54:25 +0200 byteify-strings: add --version argument
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:54:25 +0200] rev 42701
byteify-strings: add --version argument This is indispensable for automated tools to detect changes in behavior.
Tue, 06 Aug 2019 14:49:30 +0200 byteify-strings: add space in special comments to silence flake8 error
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:49:30 +0200] rev 42700
byteify-strings: add space in special comments to silence flake8 error This is done soon enough that nobody has had the time to use this feature yet.
Thu, 18 Jul 2019 17:10:38 +0800 revset: drop argument when it's None
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:10:38 +0800] rev 42699
revset: drop argument when it's None getstack's definition is `getstack(repo, rev=None)`, so providing None explicitly is unnecessary. Moreover, when x is not None, it's definitely not a revision but a part of a parsed tree of revset arguments. Differential Revision: https://phab.mercurial-scm.org/D6707
Thu, 18 Jul 2019 17:07:34 +0800 stack: remove unnecessary reverse() predicate
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:07:34 +0800] rev 42698
stack: remove unnecessary reverse() predicate Stack already sorts revisions, so no need to do it twice. This change was a part of D2400, which didn't land for other reasons. See also D2399, where this change was suggested. Differential Revision: https://phab.mercurial-scm.org/D6706
Sat, 03 Aug 2019 16:47:49 -0700 automation: increase root volume size on Linux
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:47:49 -0700] rev 42697
automation: increase root volume size on Linux It is close to full in the AMI. I actually ran out of space running tests without increasing the volume size! Differential Revision: https://phab.mercurial-scm.org/D6716
Sat, 03 Aug 2019 16:03:11 -0700 automation: install Rust in Linux environment
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:03:11 -0700] rev 42696
automation: install Rust in Linux environment This will install Rust 1.31.1, 1.34.2, and whatever stable is at the time the install runs. We install 1.31.1 as our minimum supported Rust version (I think that's what we're currently targeting) and 1.34 because that's what Debian 10 is shipping. Differential Revision: https://phab.mercurial-scm.org/D6715
Sat, 03 Aug 2019 14:17:41 -0700 automation: update packages in requirements files
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:17:41 -0700] rev 42695
automation: update packages in requirements files We like keeping up to date. The content of the autogenerated files changed slightly because I used a newer version of `pip-compile` than what was used previously. Differential Revision: https://phab.mercurial-scm.org/D6714
Sat, 03 Aug 2019 14:04:31 -0700 automation: install latest Python versions
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:04:31 -0700] rev 42694
automation: install latest Python versions This required bumping the pyenv commit so the new versions are available. Differential Revision: https://phab.mercurial-scm.org/D6713
Thu, 01 Aug 2019 03:15:58 +0200 upgrade: introduce the internal code for revlog cloning selection
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 03:15:58 +0200] rev 42693
upgrade: introduce the internal code for revlog cloning selection For now we still clone every single revlogs but all the selection mechanism is now in place in the lower layer. The next changesets will introduce the user interface part of the selection.
Thu, 01 Aug 2019 11:02:12 -0700 relnotes: copy "next" to "5.1" and clear "next" stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Aug 2019 11:02:12 -0700] rev 42692
relnotes: copy "next" to "5.1" and clear "next" To avoid merge conflicts, we want to avoid modifying the file on multiple branches in parallel. This patch is therefore meant to be applied to the stable branch and then quickly be merged to default (at least before edits are made to relnotes/next there). Another option would have been to copy the file on the stable branch and to clear it on the default branch. However, that still results in conflicts if the copy is edited on the stable branch (Mercurial would try to apply the changes from the default branch to it). We could also delete the file in one commit and recreate it in another commit. However, Mercurial is quite inconsistent in what it considers a break in history (see test-copies-unrelated.t), so I'd like to avoid that. Differential Revision: https://phab.mercurial-scm.org/D6705
Tue, 30 Jul 2019 19:58:44 +0200 upgrade: introduce a _copyrevlog method
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 30 Jul 2019 19:58:44 +0200] rev 42691
upgrade: introduce a _copyrevlog method This function copies a revlog from the old store to the new one, without re-adding all deltas manually. This will eventually save a lot of time when some revlog does not needs any conversions. Code actually using this will be introduced in later changesets.
Sat, 27 Jul 2019 19:25:47 +0200 upgrade: rename `_copyrevlogs` to `_clonerevlogs`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 27 Jul 2019 19:25:47 +0200] rev 42690
upgrade: rename `_copyrevlogs` to `_clonerevlogs` The underlying revlog method is named `clone`, keeping the naming consistent seems clearer. This is motivated to clarify the difference with an (upcoming) function that simply copy revlog files as is.
Sat, 27 Jul 2019 19:58:17 +0200 upgrade: walk the source store file only once
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 27 Jul 2019 19:58:17 +0200] rev 42689
upgrade: walk the source store file only once I don't expect this to have a significant performance impact, but it seems simpler and saner to do the operation only once and to keep the result around.
Wed, 12 Jun 2019 14:22:49 +0100 upgrade: always use full text if "full-add" mode is enable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 14:22:49 +0100] rev 42688
upgrade: always use full text if "full-add" mode is enable We should not be using a delta since the goal is to perform a full addition from scratch in all cases. Without this patch, `hg debugupgraderepo --optimize re-delta-fulladd --run` can crash.
Sun, 04 Aug 2019 22:14:26 +0200 byteify-strings: fix misalignment with multi-line parenthesis
Raphaël Gomès <rgomes@octobus.net> [Sun, 04 Aug 2019 22:14:26 +0200] rev 42687
byteify-strings: fix misalignment with multi-line parenthesis This improves the current fix to also take into account cases where the last line ended on the opening `(`, `[` or `{` and adds a regression test.
Fri, 02 Aug 2019 16:54:02 +0200 byteify-strings: add test for byteify-strings.py
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:54:02 +0200] rev 42686
byteify-strings: add test for byteify-strings.py This tests the basic features expected from this script, some cases may not be covered yet. A future patch will demonstrate an issue with multi-line `(`, `[` and `{` alignment and propose a fix.
Sun, 04 Aug 2019 20:59:21 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Aug 2019 20:59:21 +0900] rev 42685
merge with stable
Sat, 03 Aug 2019 12:13:51 -0700 automation: push changes affecting .hgtags stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 12:13:51 -0700] rev 42684
automation: push changes affecting .hgtags When I went to build the 5.1 tag using the in-repo automation, the automatic version calculation failed to deduce the clean 5.1 version string because we had only pushed the changeset corresponding to the 5.1 tag and not the changeset containing the 5.1 tag. So from the perspective of the remote repo, the 5.1 tag didn't exist yet and automatic version deduction failed. This commit changes the `hg push` to also push all changesets affecting the .hgtags file, ensuring the remote has up-to-date tags information. I tested this by creating a local draft changeset with a dummy tag value on a different DAG head and instructed the automation to build a revision that didn't have this change to .hgtags. The tag was successfully pushed and the built package had a version number incorporating that tag. Sending this to stable so the 5.1.1 automation hopefully "just works."
Fri, 02 Aug 2019 16:17:02 +0200 byteify-strings: add cli argument to handle `attr*()` when they are methods
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:17:02 +0200] rev 42683
byteify-strings: add cli argument to handle `attr*()` when they are methods Certain code bases have useful utils that wrap the builtin functions, and are called like `util.setattr`.
Fri, 21 Jun 2019 03:50:40 +0200 bookmarks: actual fix for race condition deleting bookmark stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:40 +0200] rev 42682
bookmarks: actual fix for race condition deleting bookmark This is a simple but efficient fix to prevent the issue tested in `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic approach where filecache learn to depend on each other, but that would not be suitable for stable. The issue is complicated enough that I documented the race and its current solution as inline comment. See this comment for details on the fix.
Thu, 01 Aug 2019 16:22:47 +0200 strip: access bookmark before getting a reference to changelog stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 16:22:47 +0200] rev 42681
strip: access bookmark before getting a reference to changelog Bookmark access might invalidate the current changelog (to make sure both are in a reasonable synchronisation state). So we should grab the reference to changelog after we access bookmark. Otherwise we risk using a dead object for the whole strip process. (note: this dead object business probably requires a new layers of checking)
Thu, 01 Aug 2019 15:59:52 +0200 test: use a more verbose output in the test stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 15:59:52 +0200] rev 42680
test: use a more verbose output in the test While debugging some test failure, I released the test never checks if the relevant changesets were preserved. So I am updating the test from `hg parents` usage to `hg log -G` with a special template. This increase the area covered by the test and clarify the test failures.
Fri, 02 Aug 2019 16:14:00 +0200 byteify-strings: simplify default value for `--treat-as-kwargs`
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:14:00 +0200] rev 42679
byteify-strings: simplify default value for `--treat-as-kwargs`
Fri, 02 Aug 2019 10:18:22 +0200 byteify-strings: add --treat-as-kwargs argument to handle kwargs-like objects
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 10:18:22 +0200] rev 42678
byteify-strings: add --treat-as-kwargs argument to handle kwargs-like objects This argument will help extensions move to Python 3 as keyword arguments should not be byte-prefixed. Most of the time, code bases will call this object `kwargs`, but other conventions exist like `opts`, so it should make sense to allow for custom names. This is a best effort solution that does minimal static checking; cases like `options = [o for o in ('a', 'b', 'c') if kwargs.get(o)]` and other just as complicated will not be detected.
Fri, 02 Aug 2019 10:10:23 +0200 byteify-strings: add helpers to check for item access or method call
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 10:10:23 +0200] rev 42677
byteify-strings: add helpers to check for item access or method call These helpers will be used in a future patch, split for ease of review.
Fri, 02 Aug 2019 09:55:32 +0200 byteify-strings: add support for ignore comments
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:55:32 +0200] rev 42676
byteify-strings: add support for ignore comments Our simple token analysis is sometimes not clever enough, we need to be able to turn off our script for parts of the code. This change introduces three special comments: - `#no-py3-transform` to tell `byteify-strings` ignore the next line - `#py3-transform: off` to ignore everything until the end of the file - `#py3-transform: on` to stop ignoring The last two can be particularly useful within Python 2/3 compatibility files.
Fri, 02 Aug 2019 09:48:13 +0200 byteify-strings: handle triple quoted strings if they are not docstrings
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:48:13 +0200] rev 42675
byteify-strings: handle triple quoted strings if they are not docstrings As with anything in this script, this is a best effort approach. Most of the time, when a triple quoted string is assigned to something, it's not a docstring.
Fri, 02 Aug 2019 09:44:11 +0200 byteify-strings: handle multi-line strings in _ensuresysstr
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:44:11 +0200] rev 42674
byteify-strings: handle multi-line strings in _ensuresysstr The current implementation did not handle calls like `repo.ui.log("first line" "other line")` correctly.
Wed, 22 May 2019 16:22:06 -0700 fix: run fixer tools in the repo root as cwd so they can use the working copy
Danny Hooper <hooper@google.com> [Wed, 22 May 2019 16:22:06 -0700] rev 42673
fix: run fixer tools in the repo root as cwd so they can use the working copy This lets fixer tools do things like find configuration files, with the caveat that they'll only see the version of that file in the working copy, regardless of what revisions are being fixed. Differential Revision: https://phab.mercurial-scm.org/D6440
Thu, 01 Aug 2019 22:03:52 +0530 config: add defaultvalue template keyword
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 01 Aug 2019 22:03:52 +0530] rev 42672
config: add defaultvalue template keyword This patch tries to fix one of the issues mentioned in issue6014. This adds a new `defaultvalue` template keyword to be used with `hg showconfig` to get the default value of the config item. Differential Revision: https://phab.mercurial-scm.org/D6704
Thu, 01 Aug 2019 12:23:07 -0400 merge with stable
Augie Fackler <augie@google.com> [Thu, 01 Aug 2019 12:23:07 -0400] rev 42671
merge with stable
Tue, 23 Jul 2019 11:12:36 +0200 module-policy: update rust extension import to use the new module policy
Raphaël Gomès <rgomes@octobus.net> [Tue, 23 Jul 2019 11:12:36 +0200] rev 42670
module-policy: update rust extension import to use the new module policy Differential Revision: https://phab.mercurial-scm.org/D6677
Sun, 21 Jul 2019 07:59:16 -0700 transaction: leave unfinished without crashing when not properly released
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 07:59:16 -0700] rev 42669
transaction: leave unfinished without crashing when not properly released I think the transaction.__del__ is there just as a last resort in case we (or an extension) forgot to release the transaction. When that happens, the repo can (or will on Python 3?) get deleted before the transaction. This leads to a crash in test-devel-warnings.t on Python 3 because we tried to access repo.dirstate, where repo was retried from a weak reference. There's not much we can do here, but let's at least avoid the crash. The user will have run `hg recover` afterwards regardless. Differential Revision: https://phab.mercurial-scm.org/D6664
Tue, 30 Jul 2019 21:36:15 +0530 unshelve: add abort on using continue and interactive together
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 30 Jul 2019 21:36:15 +0530] rev 42668
unshelve: add abort on using continue and interactive together `unshelve --continue --interactive` will not work as expected by the user as the mode of in-progress unshelve is preserved and cannot be overwritten. This patch makes `unshelve` to throw an error on using both `--continue` and `--interactive` together with `unshelve`. Differential Revision: https://phab.mercurial-scm.org/D6703
Mon, 29 Jul 2019 13:22:52 +0300 py3: add one more test to list of passing tests
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 29 Jul 2019 13:22:52 +0300] rev 42667
py3: add one more test to list of passing tests Found by buildbot. Differential Revision: https://phab.mercurial-scm.org/D6702
Mon, 29 Jul 2019 13:25:05 +0300 tests: sort imports in test-bookmarks-corner-case.t
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 29 Jul 2019 13:25:05 +0300] rev 42666
tests: sort imports in test-bookmarks-corner-case.t test-check-module-imports.t breaks on py3 without this change. Differential Revision: https://phab.mercurial-scm.org/D6701
Thu, 01 Aug 2019 12:14:52 -0400 Added signature for changeset e91930d712e8 stable
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:52 -0400] rev 42665
Added signature for changeset e91930d712e8
Thu, 01 Aug 2019 12:14:50 -0400 Added tag 5.1 for changeset e91930d712e8 stable
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:50 -0400] rev 42664
Added tag 5.1 for changeset e91930d712e8
Fri, 26 Jul 2019 10:47:06 -0700 fix: add some new test cases
Danny Hooper <hooper@google.com> [Fri, 26 Jul 2019 10:47:06 -0700] rev 42663
fix: add some new test cases These cover a couple of behaviors we were testing at Google that weren't covered here before. Differential Revision: https://phab.mercurial-scm.org/D6698
Wed, 24 Jul 2019 00:44:12 +0530 unshelve: store information about interactive mode in shelvedstate
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 00:44:12 +0530] rev 42662
unshelve: store information about interactive mode in shelvedstate This is a follow-up patch to 5162753c4c14. This makes `unshelve` stores the information about interactive mode on conflicts. Differential Revision: https://phab.mercurial-scm.org/D6679
Sun, 28 Jul 2019 18:32:31 -0700 automation: execute powershell when connecting stable 5.1
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:32:31 -0700] rev 42661
automation: execute powershell when connecting For some reason, the ability to execute PS scripts appears to come online after the ability to execute regular command scripts. This is creating race conditions when connecting to instances resulting in our wait_for_winrm() returning before PS is available leading to an exception being thrown in other code. Let's change the client connection code to execute a minimal PS script so we can try to trap the exception in wait_for_winrm().
Sun, 28 Jul 2019 18:16:08 -0700 automation: allow exit code of 1 for `hg push` stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:16:08 -0700] rev 42660
automation: allow exit code of 1 for `hg push` `hg push` exits 1 for no-ops. No-op pushes should be fine in the context of automation.
Thu, 25 Jul 2019 21:28:29 +0900 curses: do not setlocale() at import time (issue5261) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 25 Jul 2019 21:28:29 +0900] rev 42659
curses: do not setlocale() at import time (issue5261) setlocale() can break date formatting/parsing functions because they are locale dependent. We should avoid doing setlocale() as possible. This patch moves setlocale() just before curses.wrapper(), which function is documented to "initialize curses." I don't know the details about the curses initialization, but I *think* this would work as well. Maybe we can extract a curses setup function later. https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128788.html
Wed, 24 Jul 2019 18:20:01 +0530 unshelve: create a matcher only if required on creating unshelve ctx
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:20:01 +0530] rev 42658
unshelve: create a matcher only if required on creating unshelve ctx Differential Revision: https://phab.mercurial-scm.org/D6687
Wed, 24 Jul 2019 18:10:50 +0530 unshelve: changes how date is set on interactive mode
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:10:50 +0530] rev 42657
unshelve: changes how date is set on interactive mode On an interactive unshelve, the remaining changes are shelved again for later. This patch modifies the date of remaining shelved change to the time of interactive shelve. Differential Revision: https://phab.mercurial-scm.org/D6685
Wed, 24 Jul 2019 09:06:25 +0530 unshelve: unify logic around creating an unshelve changeset
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 09:06:25 +0530] rev 42656
unshelve: unify logic around creating an unshelve changeset This is a follow-up patch to 5162753c4c14 on addressing reviews on the commit. This unifies the logic around creating an unshelve changeset. Differential Revision: https://phab.mercurial-scm.org/D6683
Wed, 24 Jul 2019 16:19:00 -0700 fix: ignore fixer tool configurations that are missing patterns
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:19:00 -0700] rev 42655
fix: ignore fixer tool configurations that are missing patterns This is to prevent a crash under the same circumstances. This is also to avoid data loss due to accidental application of a fixer tool to all files, if the matching logic somehow changed to that effect. Affecting all files until otherwise configured would be dangerous, and not very useful. We shouldn't abort because there may be other fixers, and it may still be useful to run them without having to adjust configuration. A user might not feel confident in changing configs, for example. Differential Revision: https://phab.mercurial-scm.org/D6693
Wed, 24 Jul 2019 16:21:12 -0700 fix: add a test case around the effect of cwd on pattern matching
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:21:12 -0700] rev 42654
fix: add a test case around the effect of cwd on pattern matching This was not covered by previous tests. It is related to a regression encountered at Google due to misconfiguration of [fix]. Differential Revision: https://phab.mercurial-scm.org/D6692
Wed, 24 Jul 2019 16:22:45 -0700 fix: remove support for :fileset sub-config in favor of :pattern
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:22:45 -0700] rev 42653
fix: remove support for :fileset sub-config in favor of :pattern Differential Revision: https://phab.mercurial-scm.org/D6691
Tue, 23 Jul 2019 15:01:28 -0400 fsmonitor: add support for extra `hg debuginstall` data
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 15:01:28 -0400] rev 42652
fsmonitor: add support for extra `hg debuginstall` data This might make some things easier to debug, and for default bug report templates it'll help collect more data from users all at once. I don't actually need fsmonitor in our bug reports (we don't use it), but this demonstrates the utility of the preceding patches without having to add new things to core. Differential Revision: https://phab.mercurial-scm.org/D6682
Tue, 23 Jul 2019 14:37:51 -0400 debugcommands: add support for extensions adding their own debug info
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:37:51 -0400] rev 42651
debugcommands: add support for extensions adding their own debug info We've had a couple of cases where it'd be handy at Google to add data to `hg debuginstall`'s output. We've kludged around that at various times, but it seems reasonable to let extensions add their own data here so extension maintainers can get useful extra data. Differential Revision: https://phab.mercurial-scm.org/D6681
Tue, 23 Jul 2019 14:36:38 -0400 fsmonitor: refactor watchmanclient.client to accept ui and repo path
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:36:38 -0400] rev 42650
fsmonitor: refactor watchmanclient.client to accept ui and repo path This will make my next patch simpler. Differential Revision: https://phab.mercurial-scm.org/D6680
Mon, 22 Jul 2019 19:10:59 -0700 contrib: install Python 3.8b2 instead of 3.8a2 stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:10:59 -0700] rev 42649
contrib: install Python 3.8b2 instead of 3.8a2 Let's install the most recent Python 3.8 distribution. Differential Revision: https://phab.mercurial-scm.org/D6674
Mon, 22 Jul 2019 19:06:20 -0700 automation: make Windows base image name configurable stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:06:20 -0700] rev 42648
automation: make Windows base image name configurable Since automation broke in the middle of the 5.0 release cycle, there's a good chance it will break again in the future. While a robust solution might be to search for all available images and choose the newest one, it does seem useful to be able to explicitly choose the name of the image to find and use so users can opt in to using a different image. This commit implements that functionality. Differential Revision: https://phab.mercurial-scm.org/D6673
Mon, 22 Jul 2019 18:55:52 -0700 automation: extract strings to constants stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:55:52 -0700] rev 42647
automation: extract strings to constants Differential Revision: https://phab.mercurial-scm.org/D6672
Mon, 22 Jul 2019 18:52:58 -0700 automation: use newer Windows base image stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:52:58 -0700] rev 42646
automation: use newer Windows base image It looks like the old base image disappeared. Let's use a newer image that exists today. Differential Revision: https://phab.mercurial-scm.org/D6671
Mon, 22 Jul 2019 17:44:19 -0700 copies: fix crash on in changeset-centric tracing from commit to itself stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 17:44:19 -0700] rev 42645
copies: fix crash on in changeset-centric tracing from commit to itself When we trace copies from a changeset to itself, the "work" queue ends up empty and we hit the "assert False" after it. It was only the last of the three added tests that failed before this patch. That is because the other two cases have fast paths, so _committedforwardcopies() is never reached. Differential Revision: https://phab.mercurial-scm.org/D6675
Tue, 23 Jul 2019 12:03:24 +0530 unshelve: add help text on --interactive in verbose mode stable
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 23 Jul 2019 12:03:24 +0530] rev 42644
unshelve: add help text on --interactive in verbose mode This is a follow-up patch to rHG9eace8d6d537. This modifies the help text of unshelve in verbose mode to mention the details about `--interactive` flag. Differential Revision: https://phab.mercurial-scm.org/D6676
Mon, 22 Jul 2019 06:33:11 -0400 amend: stop committing unrequested file reverts (issue6157) stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:11 -0400] rev 42643
amend: stop committing unrequested file reverts (issue6157) Differential Revision: https://phab.mercurial-scm.org/D6667
Mon, 22 Jul 2019 06:33:00 -0400 amend: add a test for a simplified version of issue6157 stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:00 -0400] rev 42642
amend: add a test for a simplified version of issue6157 Differential Revision: https://phab.mercurial-scm.org/D6666
Sun, 21 Jul 2019 18:04:05 -0700 py: error out if a "skip" character was given with non-dict to util.dirs() stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 18:04:05 -0700] rev 42641
py: error out if a "skip" character was given with non-dict to util.dirs() util.dirs() keeps track of the directories in its input collection. If a "skip" character is given to it, it will assume the input is a dirstate map and it will skip entries that are in the given "skip" state. I think this is used only for skipping removed entries ("r") in the dirtate. The C implementation of util.dirs() errors out if it was given a skip character and a non-dict was passed. The pure implementation simply ignored the request skip state. Let's make it easier to discover bugs here by erroring out in the pure implementation too. Let's also switch to checking for the dict-ness, to make the C implementation (since that's clearly been sufficient for many years). This last change makes test-issue660.t pass on py3 in pure mode, since the old check was for existence of iteritems(), which doesn't exist on py3. Differential Revision: https://phab.mercurial-scm.org/D6669
Mon, 22 Jul 2019 09:55:05 -0700 py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 09:55:05 -0700] rev 42640
py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc Both places should have been changed from 185 to 187. Differential Revision: https://phab.mercurial-scm.org/D6668
Mon, 22 Jul 2019 14:08:56 -0400 Added signature for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:56 -0400] rev 42639
Added signature for changeset e386b5f4f836
Mon, 22 Jul 2019 14:08:54 -0400 Added tag 5.1rc0 for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:54 -0400] rev 42638
Added tag 5.1rc0 for changeset e386b5f4f836
Mon, 22 Jul 2019 14:00:33 -0400 merge default into stable for 5.1 release stable 5.1rc0
Augie Fackler <augie@google.com> [Mon, 22 Jul 2019 14:00:33 -0400] rev 42637
merge default into stable for 5.1 release
Sun, 21 Jul 2019 14:42:01 +0900 rust-filepatterns: unescape comment character property
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 14:42:01 +0900] rev 42636
rust-filepatterns: unescape comment character property There were multiple issues in the original implementation: a. the local variable "line" dropped soon after replace_slice() applied b. replace_slice() was noop since br"\#".len() != b"#" This patch uses bytes::Regex::replace_all() since it seems the simplest way to replace bytes of arbitrary length, and I don't think we have to avoid using Regexp here.
Sun, 21 Jul 2019 13:00:54 +0900 rust-filepatterns: use literal b'#' instead of cast
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:00:54 +0900] rev 42635
rust-filepatterns: use literal b'#' instead of cast
Sun, 21 Jul 2019 12:46:57 +0900 rust-filepatterns: fix type of warnings tuple to (bytes, bytes)
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 12:46:57 +0900] rev 42634
rust-filepatterns: fix type of warnings tuple to (bytes, bytes) Otherwise warn() in match.py would fail if the warning contains non-ASCII character. We might want to add a thin ByteString wrapper around Vec<u8> to implement ToPyObject<ObjectType = PyBytes>, but I'm not sure.
Sun, 21 Jul 2019 13:48:29 +0900 hgignore: add escape syntax test for glob patterns
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:48:29 +0900] rev 42633
hgignore: add escape syntax test for glob patterns The last example, [\#], is what the rust implementation fails to parse. The other escapes can be removed by regexp engine or _globre().
Sun, 21 Jul 2019 13:37:24 +0900 hgignore: add a few more weird patterns to test case
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:37:24 +0900] rev 42632
hgignore: add a few more weird patterns to test case
Sun, 21 Jul 2019 13:30:47 +0900 hgignore: update \-escape test to reflect actual behavior
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:30:47 +0900] rev 42631
hgignore: update \-escape test to reflect actual behavior "\\<char>" is not an escape character but "\\" + <char>.
Sat, 20 Jul 2019 11:04:49 -0700 py3: add a b'' prefix in tests/test-convert-identity.t
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 Jul 2019 11:04:49 -0700] rev 42630
py3: add a b'' prefix in tests/test-convert-identity.t Differential Revision: https://phab.mercurial-scm.org/D6662
Fri, 19 Jul 2019 09:43:50 -0700 lookup: don't use "00changelog.i@None" when lookup of prefix fails
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Jul 2019 09:43:50 -0700] rev 42629
lookup: don't use "00changelog.i@None" when lookup of prefix fails We were shadowing the "node" variable, so we always passed None to the LookupError instead of the node we meant to pass. (This showed up in py3 tests since py3 doesn't like to format None using "%s".) Differential Revision: https://phab.mercurial-scm.org/D6661
Thu, 18 Jul 2019 14:23:21 -0400 py3: fix test-setdiscovery.t on Python 3 by conditionalizing two lines
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:23:21 -0400] rev 42628
py3: fix test-setdiscovery.t on Python 3 by conditionalizing two lines I'm not clear why this behaves very slightly differently on Python 3, but I'm also not concerned about it. Differential Revision: https://phab.mercurial-scm.org/D6658
Fri, 19 Jul 2019 01:49:10 +0530 commands: removed part of description from abort and continue
Taapas Agrawal <taapas2897@gmail.com> [Fri, 19 Jul 2019 01:49:10 +0530] rev 42627
commands: removed part of description from abort and continue The description for registration of new `continuefunc` or `abortfunc` is removed as it is not required from user perspective. Differential Revision: https://phab.mercurial-scm.org/D6660
Sat, 20 Jul 2019 22:18:22 -0400 tests: glob over some timing numbers in test-shelve.t
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Jul 2019 22:18:22 -0400] rev 42626
tests: glob over some timing numbers in test-shelve.t The Windows bot is slow enough that it was 2s in the first hunk. Differential Revision: https://phab.mercurial-scm.org/D6663
Thu, 18 Jul 2019 14:18:20 -0400 py3: another passing test
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:18:20 -0400] rev 42625
py3: another passing test Differential Revision: https://phab.mercurial-scm.org/D6656
Thu, 18 Jul 2019 14:19:41 -0400 cleanup: remove redundant import
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:19:41 -0400] rev 42624
cleanup: remove redundant import For some reason the import checker only caught this on py3. Differential Revision: https://phab.mercurial-scm.org/D6657
Thu, 18 Jul 2019 21:10:17 +0530 shelve: modify help text on --interactive
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 21:10:17 +0530] rev 42623
shelve: modify help text on --interactive We now have `unshelve --interactive` after rHG5162753c4c14. So, the help text on `shelve --interactive` suggesting that it only works for `shelve` can be removed. Differential Revision: https://phab.mercurial-scm.org/D6654
Thu, 18 Jul 2019 20:54:26 +0530 unshelve: mark unshelve interactive as experimental
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 20:54:26 +0530] rev 42622
unshelve: mark unshelve interactive as experimental This is a follow-up patch to rHG5162753c4c14. We have the logic for interactive unshelve under `_rebaserestorecommit()`. So, we might get conflicts even if there are conflicting changes other than selected changes by the user. We should mark unshelve `--interactive` as `EXPERIMENTAL` until we solve this issue. Differential Revision: https://phab.mercurial-scm.org/D6653
Tue, 02 Jul 2019 12:59:58 -0400 commit: improve the files field of changelog for merges
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:59:58 -0400] rev 42621
commit: improve the files field of changelog for merges Currently, the files list of merge commits repeats all the deletions (either actual deletions, or files that got renamed) that happened between base and p2 of the merge. If p2 is the main branch, the list can easily be much bigger than the change being merged. This results in various problems worth improving: - changelog is bigger than necessary - `hg log directory` lists many unrelated merge commits, and `hg log -v -r commit` frequently fills multiple screens worth of files - it possibly slows down adjustlinkrev, by forcing it to read more manifests, and that function can certainly be a bottleneck - the server side of pulls can waste a lot of time simply opening the filelogs for pointless files (the constant factors for opening even a tiny filelog is apparently pretty bad) So stop listing such files as described in the code. Impacted merge commits and their descendants get a different hash than they would have without this. This doesn't seem problematic, except for convert. The previous commit helped with that in the hg->hg case (but if you do svn->hg twice from scratch, hashes can still change). The rest of the description is numbers. I don't have much to report, because recreating the files list of existing repositories is not easy: - debugupgradeformat and bundle/unbundle don't recreate the list - export/import tends to choke quickly applying patches or on description that contain diffs, - merge commits from the convert extension don't have the right files list for reasons orthogonal to the current commit - replaying the merge with hg update/hg merge/hg revert --all/hg commit can end up failing in hg revert - I wasn't sure that using debugsetparents + debugrebuilddirstate would really build the right thing I measured commit time before and after this change, in a case with no files filtered out, several files filtered out (no difference) and 5k files filtered out (+1% time). Recreating the 100 more recent merges in a private repo, the concatenated uncompressed files lists goes from 1.12MB to 0.52MB. Excluding 3 merges that are not representative, then the size goes from 570k to 15k. I converted part of mozilla-central, and observed file list shrinking quite a bit too, starting at the very first merge, 733641d9feaf, going from 550 files to 10 files (although they have relatively few merges, so they probably wouldn't care). Differential Revision: https://phab.mercurial-scm.org/D6613
Sat, 13 Jul 2019 23:45:32 -0400 convert: add a config option to help doing identity hg->hg conversion
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 13 Jul 2019 23:45:32 -0400] rev 42620
convert: add a config option to help doing identity hg->hg conversion I want to change the computation of the list of files modified by a commit. In principle, this would simply change a cache. But since this information is stored in commits rather than a cache, changing it means changing commit hashes (going forward). Some users rely on the convert extension from hg to hg not changing hashes when nothing changes (usually). Allow these users to preserve hashes despite changes to the changelog files computation by reusing these files lists when the manifest is unchanged (since these files list are derived from the manifest). Differential Revision: https://phab.mercurial-scm.org/D6643
Tue, 02 Jul 2019 12:55:51 -0400 tests: show the files fields of changelogs for many merges
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:55:51 -0400] rev 42619
tests: show the files fields of changelogs for many merges I don't think there's coverage for many of the subtle cases, and I found it hard to understand what the code is doing by reading it. The test takes 40s to run on a laptop, or 9s with --chg. I have yet to find a description of what the files field is supposed to be for merges. I thought it could be one of: 1. the files added/modified/removed relative to p1 (wouldn't seem useful, but `hg diff -c -r mergerev` has this behavior) 2. the files with filelog nodes not in either parent (i.e., what is needed to create a bundle out of a commit) 3. the files added/removed/modified files by merge itself [1] It's clearly not 1, because file contents merges are symmetric. It's clearly not 2 because removed files and exec bit changes are listed. It's also not 3 but I think it's intended to be 3 and the differences are bugs. Assuming 3, the test shows that, for merges, the list of files both overapproximates and underapproximates. All the cases involve file changes not in the filelog but in the manifest (existence of file at revision, exec bit and file vs symlink). I didn't look at all underapproximations, but they looked minor. The two overapproximations are problematic though because they both cause potentially long lists of files when merging cleanly. [1] even what it means for the merge commit itself to change a file is not completely trivial. A file in the merge being the same as in one of the parent is too lax as it would consider that merges change nothing when they revert all the changes done on one side. The criteria used in the test and in the next commit for "merge didn't touch a file" is: - the parents and the merge all have the same file - or, one parent didn't touch the file and the other parent contains the same file as the merge Differential Revision: https://phab.mercurial-scm.org/D6612
Tue, 16 Jul 2019 19:18:16 +0100 phabricator: handle local:commits time being string or int
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 19:18:16 +0100] rev 42618
phabricator: handle local:commits time being string or int When setting local:commits arcanist has different behaviour depending on whether the repo is git or hg. With hg it sets the time as a number, since it calls PHP's strtotime on the value, but with git it sets it as a string. Normally this wouldn't be an issue since phabread wouldn't be interacting with Phabricator Revisions for git repos, but Mozilla has a secondary workflow for git users that uses the git-cinnabar tool to interact with their hg repos. When a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central it makes use of Mozilla's fork of arcanist, which works with their local git version of m-c, and thus sets the local:commit time as a string, and then translates the commit hashes. Currently when encountering such DREVS phabread dies with "TypeError: %d format: a number is required, not str". phabsend also used to set it as a string but wouldn't have encountered the issue with its own DREVs since it would read hg:meta first. Differential Revision: https://phab.mercurial-scm.org/D6650
Tue, 16 Jul 2019 18:38:38 +0100 phabricator: demonstrate broken phabread on string local:commit times
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 18:38:38 +0100] rev 42617
phabricator: demonstrate broken phabread on string local:commit times Differential Revision: https://phab.mercurial-scm.org/D6649
Tue, 02 Jul 2019 18:02:12 +0530 unshelve: add interactive mode
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 02 Jul 2019 18:02:12 +0530] rev 42616
unshelve: add interactive mode Until now, there is no way to `unshelve` selected changes only from the stored shelve as given in issue6162. This patch makes `unshelve` perform with certain changes only by adding an interactive mode. Differential Revision: https://phab.mercurial-scm.org/D6596
Sun, 07 Jul 2019 10:54:41 -0400 blackbox: disable extremely verbose logging (issue6110)
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 07 Jul 2019 10:54:41 -0400] rev 42615
blackbox: disable extremely verbose logging (issue6110) This is maybe not the best way to go about fixing this, but anything is better than the status quo. Differential Revision: https://phab.mercurial-scm.org/D6611
Wed, 17 Jul 2019 22:24:17 +0530 continue: added support for unshelve
Taapas Agrawal <taapas2897@gmail.com> [Wed, 17 Jul 2019 22:24:17 +0530] rev 42614
continue: added support for unshelve This patch adds the support for `ushelve` in `hg continue` plan. `hgcontinueunshelve()` has been created for independent calls. In case an interrupted unshelve is resumed via hg continue the shelvedstate needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgcontinueunshelve()` is then registered as `continuefunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6652
Tue, 16 Jul 2019 01:59:28 +0530 continue: added support for rebase
Taapas Agrawal <taapas2897@gmail.com> [Tue, 16 Jul 2019 01:59:28 +0530] rev 42613
continue: added support for rebase This adds support of rebase to hg continue plan. An independent continue logic for rebase is created under continuerebase() function. For this a seperate rebaseruntime object is created under the function to handle an interrupted rebasestate. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6646
Mon, 15 Jul 2019 22:23:31 +0530 continue: added logic for hg continue
Taapas Agrawal <taapas2897@gmail.com> [Mon, 15 Jul 2019 22:23:31 +0530] rev 42612
continue: added logic for hg continue This is part of GSoC19 project `Implement abort and continue commands`. This patch is part of the continue plan. This adds the basic logic for hg continue. This command aborts an multistep operation like graft, histedit, rebase, transplant and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under statemod. This API is extended to support hg continue by adding a method to register the abort logic as a function (here continuefunc). Once the unfinished operation is determined the registered logic is used to resume the command in case it is interrupted. The benefit of this kind of framework is that any new extension developed can support hg continue by registering the command and logic under statedetection API. hg continue currently supports --dry-run/-n flag only. It is used to dry run hg abort Differential Revision: https://phab.mercurial-scm.org/D6645
Wed, 17 Jul 2019 18:15:51 +0200 rust-utils: remove buggy assertion
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Jul 2019 18:15:51 +0200] rev 42611
rust-utils: remove buggy assertion While this assertion had good intentions, it broke existing behavior with a nasty panic. Differential Revision: https://phab.mercurial-scm.org/D6651
Wed, 10 Jul 2019 17:41:07 +0200 rust-utils: add docstrings and doctests for utils.rs
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Jul 2019 17:41:07 +0200] rev 42610
rust-utils: add docstrings and doctests for utils.rs Differential Revision: https://phab.mercurial-scm.org/D6635
Tue, 02 Jul 2019 17:15:03 +0200 rust: switch hg-core and hg-cpython to rust 2018 edition
Raphaël Gomès <rgomes@octobus.net> [Tue, 02 Jul 2019 17:15:03 +0200] rev 42609
rust: switch hg-core and hg-cpython to rust 2018 edition Many interesting changes have happened in Rust since the Oxidation Plan was introduced, like the 2018 edition and procedural macros: - Opting in to the 2018 edition is a clear benefit in terms of future proofing, new (nice to have) syntactical sugar notwithstanding. It also has a new non-lexical, non-AST based borrow checker that has fewer bugs(!) and allows us to write correct code that in some cases would have been rejected by the old one. - Procedural macros allow us to use the PyO3 crate which maintainers have expressed the clear goal of compiling on stable, which would help in code maintainability compared to rust-cpython. In this patch are the following changes: - Removing most `extern crate` uses - Updating `use` clauses (`crate` keyword, nested `use`) - Removing `mod.rs` in favor of an aptly named module file Like discussed in the mailing list ( https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html ), until Rust integration in Mercurial is considered to be out of the experimental phase, the maximum version of Rust allowed is whatever the latest version Debian packages. Differential Revision: https://phab.mercurial-scm.org/D6597
Fri, 12 Jul 2019 11:08:31 +0200 rust-utils: use new find_dirs iterator
Raphaël Gomès <rgomes@octobus.net> [Fri, 12 Jul 2019 11:08:31 +0200] rev 42608
rust-utils: use new find_dirs iterator In cad3dde7a573, the `find_dirs` util was introduced, but the second changeset that made use of it didn't apply. This change fixes the issue. Differential Revision: https://phab.mercurial-scm.org/D6639
Tue, 16 Jul 2019 00:00:17 -0400 inno: correct the path display in a literal block of the readme
Matt Harbison <matt_harbison@yahoo.com> [Tue, 16 Jul 2019 00:00:17 -0400] rev 42607
inno: correct the path display in a literal block of the readme Otherwise, the path components allrantogether. Differential Revision: https://phab.mercurial-scm.org/D6648
Mon, 15 Jul 2019 15:29:22 -0700 copies: remove unnecessary override of p[12]copies() in workingctx
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Jul 2019 15:29:22 -0700] rev 42606
copies: remove unnecessary override of p[12]copies() in workingctx The implementation is identical to the version inherited from basectx. Differential Revision: https://phab.mercurial-scm.org/D6647
Fri, 12 Jul 2019 19:38:18 -0400 tests: properly position conditional output on Windows in test-subrepo.t
Matt Harbison <matt_harbison@yahoo.com> [Fri, 12 Jul 2019 19:38:18 -0400] rev 42605
tests: properly position conditional output on Windows in test-subrepo.t The test runner doesn't always guess the right location when optional output is missing. This goes with f6540aba8e3e. Differential Revision: https://phab.mercurial-scm.org/D6640
Thu, 11 Jul 2019 03:08:28 +0530 abort: removed labels argument from abortmerge()
Taapas Agrawal <taapas2897@gmail.com> [Thu, 11 Jul 2019 03:08:28 +0530] rev 42604
abort: removed labels argument from abortmerge() Labels are used to label the code that belongs to `working copy` and `merge rev` in case of a conflicted state. No such labelling is required while aborting merge as conflicted parts are reverted to normal. Differential Revision: https://phab.mercurial-scm.org/D6638
Fri, 12 Jul 2019 23:34:24 -0700 py3: source-transform only call-sites of iteritems(), not definitions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:34:24 -0700] rev 42603
py3: source-transform only call-sites of iteritems(), not definitions branchmap.branchcache, among other classes, defines a iteritems(). That currently gets replaced by items() by the source transformer. That makes it harder for extensions to work with both py2 and py3, since they have to call either items() or iteritems() on branchcache. Let's not replace definitions of iteritems() (and itervalues()) and only replace the call-sites. We need to also add an items() alias to branchcache (etc) so our transformer call-sites will find it. Differential Revision: https://phab.mercurial-scm.org/D6641
Sun, 14 Jul 2019 23:21:28 -0700 py3: fix formatting of branchmap log messages with repo.filtername=None
Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Jul 2019 23:21:28 -0700] rev 42602
py3: fix formatting of branchmap log messages with repo.filtername=None `"%s" % None` does not work on py3. I've extracted a little function for producing a formatted message given the filter name. Differential Revision: https://phab.mercurial-scm.org/D6644
Sun, 14 Jul 2019 01:31:42 -0400 automation: correct the path separator in LIBPATH on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sun, 14 Jul 2019 01:31:42 -0400] rev 42601
automation: correct the path separator in LIBPATH on Windows I haven't tried building the x86 installer, but happened to notice this when working on the thg installer. Experimenting in PowerShell seems to show that LIBPATH was expanded at the end, but with ':' between, it effectively corrupted `${root}\WinSDK\Lib` and the first path in LIBPATH. Differential Revision: https://phab.mercurial-scm.org/D6642
Sun, 30 Jun 2019 01:07:14 +0530 abort: added support for merge
Taapas Agrawal <taapas2897@gmail.com> [Sun, 30 Jun 2019 01:07:14 +0530] rev 42600
abort: added support for merge This adds support of `hg merge --abort` to `hg abort` plan. This involves refactoring `hg.merge` into two different functions removing the abort logic of `merge` from `hg.merge` and then creating a seperate `hg.abortmerge` to handle the abort logic so that the abortion of merge can be called independently. `hg.abortmerge` is then registered as `abortfunc` for the state detection API so that `commands.abort` can use it to deal with an unfinished merge operation. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6588
Wed, 26 Jun 2019 22:15:07 +0530 abort: added support for unshelve
Taapas Agrawal <taapas2897@gmail.com> [Wed, 26 Jun 2019 22:15:07 +0530] rev 42599
abort: added support for unshelve This patch adds the support for shelve in `hg abort` plan. For this the logic to load a `shelvedstate` and the error handling for it had been shifted to a seperate function `_loadunshelvedstate()`. This returns a tuple with `state` file and `opts.` `hgabortunshelve()` has been created for independent calls. In case abortion of `unshelve` is called via `hg abort` the `shelvedstate` needs to be loaded seperately. This has been ensured by `_loadunshelvedstate()` `hgabortunshelve()` is then registered as `abortfunc` for state detection API. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6579
Wed, 10 Jul 2019 23:11:55 +0530 unshelve: changed Corruptedstate error msg from ui.warn to error.Abort
Taapas Agrawal <taapas2897@gmail.com> [Wed, 10 Jul 2019 23:11:55 +0530] rev 42598
unshelve: changed Corruptedstate error msg from ui.warn to error.Abort This changes the message type of Corruptedstate error in case of `hg unshelve --abort` to error.Abort from warning message. This is done so as to avoid the return statement after the warning. Differential Revision: https://phab.mercurial-scm.org/D6636
Thu, 20 Jun 2019 01:08:56 +0530 mq: fix for merge detection methods
Taapas Agrawal <taapas2897@gmail.com> [Thu, 20 Jun 2019 01:08:56 +0530] rev 42597
mq: fix for merge detection methods Differential Revision: https://phab.mercurial-scm.org/D6548
Tue, 09 Jul 2019 00:03:10 -0700 py3: store _origdoc as str
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Jul 2019 00:03:10 -0700] rev 42596
py3: store _origdoc as str Since __doc__ is str, it seems natural that _origdoc also is. Differential Revision: https://phab.mercurial-scm.org/D6623
Fri, 28 Jun 2019 12:59:21 -0700 copies: follow copies across merge base without source file (issue6163)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 12:59:21 -0700] rev 42595
copies: follow copies across merge base without source file (issue6163) As in the previous patch, consider these two histories: @ 4 'rename x to y' | o 3 'add x again' | o 2 'remove x' | | o 1 'modify x' |/ o 0 'add x' @ 4 'rename x to y' | o 3 'add x again' | | o 2 'modify x' | | | o 1 'add x' |/ o 0 'base' We trace copies from the 'modify x' commit to commit 4 by going via the merge base (commit 0). When tracing file 'y' (_tracefile()) in the first case, we immediately find the rename from 'x'. We check to see if 'x' exists in the merge base, which it does, so we consider it a valid copy. In the second case, 'x' does not exist in the merge base, so it's not considered a valid copy. As a workaround, this patch makes it so we also attempt the check in mergecopies's base commit (commit 1 in the second case). That feels pretty ugly to me, but I don't have any better ideas. Note that we actually also check not only that the filename matches, but also that the file's nodeid matches. I don't know why we do that, but it was like that already before I rewrote mergecopies(). That means that the rebase will still fail in cases like this (again, it already failed before my rewrite): @ 4 'rename x to y' | o 3 'add x again with content X2' | o 2 'remove x' | | o 1 'modify x to content X2' |/ o 1 'modify x to content X1' | o 0 'add x with content X0' Differential Revision: https://phab.mercurial-scm.org/D6604
Tue, 25 Jun 2019 14:25:03 -0700 copies: filter invalid copies only at end of pathcopies() (issue6163)
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 14:25:03 -0700] rev 42594
copies: filter invalid copies only at end of pathcopies() (issue6163) copies._filter() filters out copies whose source file does not exist in the start commit or whose target file does not exist in the end commit. We do that after chaining copies with dirstate copies or backward renames from another branch. We also do at the end of the changeset-centric copy tracing. The filtering means that we will remove copies to/from files that did not exist in some intermediate commit. That is inconsistent with what we do if a file has been deleted and then re-added (we allow updating across that). Copying the two first examples from issue6163: @ 4 'rename x to y' | o 3 'add x again' | o 2 'remove x' | | o 1 'modify x' |/ o 0 'add x' @ 4 'rename x to y' | o 3 'add x again' | | o 2 'modify x' | | | o 1 'add x' |/ o 0 'base' When doing `hg rebase -r 1 -d 4` in the first case, it succeeds, but `hg rebase -r 2 -d 4` in the second case does not. That's because we chain and filter via commit 0, which does not have file 'x' in the second case. IMO, that's clearly inconsistent. So this patch removes the filtering step so it only happens at the end. If a file was temporarily removed, whether via a merge base or not, it will now still be considered the same file. That fixes issue6163 for the changeset-centric case. Differential Revision: https://phab.mercurial-scm.org/D6603
Tue, 25 Jun 2019 13:46:55 -0700 copies: inline _chainandfilter() to prepare for next patch
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 13:46:55 -0700] rev 42593
copies: inline _chainandfilter() to prepare for next patch Differential Revision: https://phab.mercurial-scm.org/D6602
Tue, 25 Jun 2019 13:33:49 -0700 copies: remove most early returns from pathcopies() and _forwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Jun 2019 13:33:49 -0700] rev 42592
copies: remove most early returns from pathcopies() and _forwardcopies() I want to split up _chainandfilter() more so the call to _filter() consistently happens at the end of pathcopies(). This prepares for that change. Differential Revision: https://phab.mercurial-scm.org/D6601
Fri, 28 Jun 2019 09:01:45 -0700 copies: move short-circuiting of dirstate copies out of _forwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Jun 2019 09:01:45 -0700] rev 42591
copies: move short-circuiting of dirstate copies out of _forwardcopies() I'd like to move the filtering of copies we do after chaining to the end of all chaining (in a single place in pathcopies()). One problem that came up when trying that was that we allow things like `hg cp -f <file> <existing file>` so the user can later amend that in. Filtering at the end would mean that we remove those copies. That would break `hg st -C`. This patch therefore moves the short-circuiting of dirstate copies into pathcopies() so we can more easily handle the dirstate-only case differently. I initially thought this might change some behavior when the user does `hg status --rev 'wdir()' --rev .` during an uncommitted merge, since _backwardrenames() would reverse the copies in that case. However, I couldn't come up with a test case where it made a difference. Differential Revision: https://phab.mercurial-scm.org/D6600
Fri, 21 Jun 2019 16:59:29 -0700 tests: add more tests of copy tracing with removed and re-added files
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jun 2019 16:59:29 -0700] rev 42590
tests: add more tests of copy tracing with removed and re-added files We had a test where the destination of a copy was removed and then added back. This patch adds similar cases where the break in history instead happens to the source file. There are three versions of this: 1. The break happens before the rename. 2. The break happens on a branch parallel to the rename (where copy tracing is done via the merge base) 3. The source is added on each side of the merge base. The break in history is thus in the form of a deletion when going backwards to the merge base and the re-add happens on the other branch. I've also added calls to `hg graft` in these cases to show the breakage in issue 6163. Another factor in these cases is matching nodeid (checked in copies._tracefile()). I've made two copies each of the cases to show the impact of that. One of these is the same as a test in test-rename-merge1.t, so I also deleted that test from there. Some of these tests currently fail, where "fail" is based on my current thinking of how things should work. I had initially thought that we should be more strict about not tracing copies across commits where the file did not exist, but issue 6163 made me reconsider. The only test case here that behaved differently in 4.9 is the exact case reported in issue 6163. Differential Revision: https://phab.mercurial-scm.org/D6599
Mon, 01 Jul 2019 14:24:51 -0700 tests: split out tests for unrelated copy source/target into separate file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Jul 2019 14:24:51 -0700] rev 42589
tests: split out tests for unrelated copy source/target into separate file I've realized only recently how many cases there are where a file is treated differently if it's considered "related" to another file (not deleted and re-added). I'll add more tests for some of these cases soon. Differential Revision: https://phab.mercurial-scm.org/D6598
Mon, 24 Jun 2019 16:01:01 -0700 subrepos: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Mon, 24 Jun 2019 16:01:01 -0700] rev 42588
subrepos: make last line of prompts <40 english chars (issue6158) Differential Revision: https://phab.mercurial-scm.org/D6572
Mon, 24 Jun 2019 16:00:39 -0700 largefiles: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Mon, 24 Jun 2019 16:00:39 -0700] rev 42587
largefiles: make last line of prompts <40 english chars (issue6158) Differential Revision: https://phab.mercurial-scm.org/D6571
Sun, 30 Jun 2019 18:32:43 +0900 rust-dirstate: add helper to iterate ancestor paths
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Jun 2019 18:32:43 +0900] rev 42586
rust-dirstate: add helper to iterate ancestor paths This is modeled after std::path::Path::ancestors(). find_dirs(b"") yields b"" because Mercurial's util.finddirs() works in that way, and the test case for DirsMultiset expects such behavior.
(0) -30000 -10000 -3000 -1000 -120 +120 +1000 +3000 tip