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.
Tue, 09 Jul 2019 20:51:48 -0400 tests: update test-commit-interactive.t for no-execbit platforms
Matt Harbison <matt_harbison@yahoo.com> [Tue, 09 Jul 2019 20:51:48 -0400] rev 42585
tests: update test-commit-interactive.t for no-execbit platforms These changes correspond with f802a75da585. Differential Revision: https://phab.mercurial-scm.org/D6624
Fri, 28 Jun 2019 00:35:52 +0530 abort: added support for histedit
Taapas Agrawal <taapas2897@gmail.com> [Fri, 28 Jun 2019 00:35:52 +0530] rev 42584
abort: added support for histedit This patch adds the support for `histedit` in `hg abort` plan. As seperate `hgaborthistedit()` function is created to handle independent calls for abortion of `histedit`. This function is then registered as `abortfunc` for state detection API. hg abort in case of `histedit` also supports ` history-editing-backup` config option. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6582
Sun, 23 Jun 2019 23:11:35 +0530 abort: added support for rebase
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 23:11:35 +0530] rev 42583
abort: added support for rebase This adds support of `rebase` to `hg abort` plan. An independent abort logic for `rebase` is created under `abortrebase()` function. For this a seperate `rebaseruntime` object is created under the function to handle an unfinished `rebasestate` and abort that using abort logic under `_prepareabortorcontinue`. Results of tests are shown. Differential Revision: https://phab.mercurial-scm.org/D6568
Sun, 23 Jun 2019 22:31:31 +0530 abort: added support for graft
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 22:31:31 +0530] rev 42582
abort: added support for graft This adds support of `graft` to `hg abort` plan. The patch creates a seperate function `cmdutil.hgabortgraft` so that abort logic for graft can be called independently. This logic is registered to the statedetection API as `abortfunc`. Results are shown as tests. Differential Revision: https://phab.mercurial-scm.org/D6567
Sun, 23 Jun 2019 20:58:01 +0530 abort: added logic for of hg abort
Taapas Agrawal <taapas2897@gmail.com> [Sun, 23 Jun 2019 20:58:01 +0530] rev 42581
abort: added logic for of hg abort This is part of `GSoC19` project `Implement abort and continue commands`. This patch is part of the `abort plan`. This adds the basic logic for `hg abort`. This command aborts an multistep operation like graft, histedit, rebase, merge 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 abort` by adding a method to register the abort logic as a function (here `abortfunc`). Once the unfinished operation is determined the registered logic is used to abort the command. The benefit of this kind of framework is that any new extension developed can support `hg abort` by registering the command and logic under statedetection API. `hg abort` currently supports `--dry-run/-n` flag only. It is used to dry run `hg abort` Further patches sequentially add support for `graft`, `rebase`, `unshelve`, `histedit` and `merge`. Differential Revision: https://phab.mercurial-scm.org/D6566
Tue, 09 Jul 2019 10:09:46 -0400 merge with stable
Augie Fackler <augie@google.com> [Tue, 09 Jul 2019 10:09:46 -0400] rev 42580
merge with stable
Tue, 09 Jul 2019 12:58:29 +0300 merge: disallow merge abort in case of an unfinished operation (issue6160)
Taapas Agrawal <taapas2897@gmail.com> [Tue, 09 Jul 2019 12:58:29 +0300] rev 42579
merge: disallow merge abort in case of an unfinished operation (issue6160) This patch disallows `hg merge --abort` in case an operation of higher precedence i.e unshelve, rebase, histedit are in unfinished states. This is done so as to avoid partial abort of these operations in case merge abort is called at an interrupted step. The patch adds a `cmdutil.getunfinishedstate` function which checks for operations under progress and returns a `statecheck` object for it. Differential Revision: https://phab.mercurial-scm.org/D6607
Mon, 08 Jul 2019 15:01:18 -0700 relnotes: document new range-select mechanism in crecord
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 15:01:18 -0700] rev 42578
relnotes: document new range-select mechanism in crecord Differential Revision: https://phab.mercurial-scm.org/D6622
Fri, 05 Jul 2019 00:17:26 +0530 statecheck: updated docstrings related to afterresolvedstates
Taapas Agrawal <taapas2897@gmail.com> [Fri, 05 Jul 2019 00:17:26 +0530] rev 42577
statecheck: updated docstrings related to afterresolvedstates Differential Revision: https://phab.mercurial-scm.org/D6606
Mon, 08 Jul 2019 14:01:01 -0400 extdata: avoid crashing inside subprocess when we get a revset parse error
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 14:01:01 -0400] rev 42576
extdata: avoid crashing inside subprocess when we get a revset parse error Differential Revision: https://phab.mercurial-scm.org/D6616
Mon, 08 Jul 2019 13:57:44 -0400 extdata: demonstrate bad behavior when a subprocess emits garbage
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:57:44 -0400] rev 42575
extdata: demonstrate bad behavior when a subprocess emits garbage Differential Revision: https://phab.mercurial-scm.org/D6615
Sun, 07 Jul 2019 23:04:55 -0700 py3: don't run source transformer on hgext3rd (extensions)
Martin von Zweigbergk <martinvonz@google.com> [Sun, 07 Jul 2019 23:04:55 -0700] rev 42574
py3: don't run source transformer on hgext3rd (extensions) It's unclear why the source transformer runs on hgext3rd. It's been like that since it was introduced in 1c22400db72d (mercurial: implement a source transforming module loader on Python 3, 2016-07-04), and that commit didn't say anything about it (but it says that it doesn't have "support [...] for extensions"). I find that the current handling of hgext3rd just makes it harder to convert extensions to Python 3. It makes you convert a bunch of strings passed to getattr() and kwargs[] to r'' that could otherwise have been left alone. It's also really confusing that the source transformer runs when you import the extension as "extensions.foo=", but not as "extension.foo=/some/path". I suppose there is small number of (very simple) extensions that would have worked without this patch that would now be broken. It seems okay to me to break those. Differential Revision: https://phab.mercurial-scm.org/D6614
Mon, 08 Jul 2019 13:10:34 -0700 crecord: provide 'X' as a range-select mechanism
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:10:34 -0700] rev 42573
crecord: provide 'X' as a range-select mechanism Differential Revision: https://phab.mercurial-scm.org/D6621
Mon, 08 Jul 2019 13:06:46 -0700 crecord: make KEY_ENTER usable in tests (by not updating UI)
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:06:46 -0700] rev 42572
crecord: make KEY_ENTER usable in tests (by not updating UI) Differential Revision: https://phab.mercurial-scm.org/D6620
Mon, 08 Jul 2019 12:38:37 -0700 crecord: fix if -> elif when handling key presses
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:38:37 -0700] rev 42571
crecord: fix if -> elif when handling key presses This shouldn't actually change any behavior, I only noticed it since I started using KEY_UP in tests, and it was complaining when it got down to the ^L handler that initscr hadn't been called yet. Differential Revision: https://phab.mercurial-scm.org/D6619
Mon, 08 Jul 2019 12:17:06 -0700 crecord: add "x" alias for space, remove test-only "TOGGLE" alias
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:17:06 -0700] rev 42570
crecord: add "x" alias for space, remove test-only "TOGGLE" alias Differential Revision: https://phab.mercurial-scm.org/D6618
Mon, 08 Jul 2019 12:15:37 -0700 crecord: stop using test-only "X" as alternative for "c"
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:15:37 -0700] rev 42569
crecord: stop using test-only "X" as alternative for "c" Differential Revision: https://phab.mercurial-scm.org/D6617
Sat, 06 Jul 2019 22:19:36 +0530 graft: moved abortgraft and readgraft to cmdutil
Taapas Agrawal <taapas2897@gmail.com> [Sat, 06 Jul 2019 22:19:36 +0530] rev 42568
graft: moved abortgraft and readgraft to cmdutil This patch moves `abortgraft` and `readgraft` to `cmdutil`. Various callers are updated accordingly. This is done because these serve as ulitlity functions for command `graft` and so that new functions regarding graft can be built from them. Differential Revision: https://phab.mercurial-scm.org/D6608
Thu, 20 Jun 2019 14:33:42 -0400 cleanup: use named constants for second arg to .seek()
Augie Fackler <augie@google.com> [Thu, 20 Jun 2019 14:33:42 -0400] rev 42567
cleanup: use named constants for second arg to .seek() Differential Revision: https://phab.mercurial-scm.org/D6556
Thu, 20 Jun 2019 14:45:52 -0700 patch: use a short, fixed-size message for last line of prompt (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 14:45:52 -0700] rev 42566
patch: use a short, fixed-size message for last line of prompt (issue6158) See issue6158 and the previous commit for examples of what might go wrong if we have some combinations of readline version and terminal and need to wrap the line. Briefly: readline may not display the beginning of the last line of the prompt, or it may print over it with the end of the prompt, making it difficult for users to know what's going on. Differential Revision: https://phab.mercurial-scm.org/D6563
Thu, 20 Jun 2019 11:40:47 -0700 filemerge: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 11:40:47 -0700] rev 42565
filemerge: make last line of prompts <40 english chars (issue6158) I've chosen <40 as the target so that other languages that may have a 2x blowup in character count can still have a chance to fit into an 80 column screen. Previously, we would show a prompt like: ``` keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path? ``` On at least some systems, if readline was in use then the last line of the prompt would be wrapped strangely if it couldn't fit entirely on one line. This strange wrapping may be just a carriage return without a line feed, overwriting the beginning of the line; example (100 columns wide, 65 character filename, and yes there's 10 spaces on the end, I assume this is to handle the user inputting longest word we provide as an option, "unresolved"): ``` ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon ``` In some cases it may partially wrap onto the next line, but still be missing earlier parts in the line, such as below (60 columns wide, 65 character filename): ``` rev], or leave (u)nresolved for some/long/dir/name/that/do s/not/work/well/with/readline/file.txt? ``` With this fix, this looks like this on a 60 column screen: ``` tool vim_with_markers (for pattern some/long/dir/name/that/d oes/not/work/well/with/readline/file.txt) can't handle binar y tool meld can't handle binary tool vim_with_markers can't handle binary tool internal:merge3 can't handle binary tool merge can't handle binary no tool found to merge some/long/dir/name/that/does/not/work /well/with/readline/file.txt file 'some/long/dir/name/that/does/not/work/well/with/readli ne/file.txt' needs to be resolved. You can keep (l)ocal [working copy], take (o)ther [merge rev ], or leave (u)nresolved. What do you want to do? ``` Differential Revision: https://phab.mercurial-scm.org/D6562
Tue, 09 Jul 2019 10:07:35 -0400 Added signature for changeset 97ada9b8d51b stable
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:35 -0400] rev 42564
Added signature for changeset 97ada9b8d51b
Tue, 09 Jul 2019 10:07:33 -0400 Added tag 5.0.2 for changeset 97ada9b8d51b stable
Augie Fackler <raf@durin42.com> [Tue, 09 Jul 2019 10:07:33 -0400] rev 42563
Added tag 5.0.2 for changeset 97ada9b8d51b
Mon, 08 Jul 2019 13:12:20 -0400 posix: always seek to EOF when opening a file in append mode stable 5.0.2
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:12:20 -0400] rev 42562
posix: always seek to EOF when opening a file in append mode Python 3 already does this, so skip it there. Consider the program: #include <stdio.h> int main() { FILE *f = fopen("narf", "w"); fprintf(f, "narf\n"); fclose(f); f = fopen("narf", "a"); printf("%ld\n", ftell(f)); fprintf(f, "troz\n"); printf("%ld\n", ftell(f)); return 0; } on macOS, FreeBSD, and Linux with glibc, this program prints 5 10 but on musl libc (Alpine Linux and probably others) this prints 0 10 By my reading of https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html this is technically correct, specifically: > Opening a file with append mode (a as the first character in the > mode argument) shall cause all subsequent writes to the file to be > forced to the then current end-of-file, regardless of intervening > calls to fseek(). in other words, the file position doesn't really matter in append-mode files, and we can't depend on it being at all meaningful unless we perform a seek() before tell() after open(..., 'a'). Experimentally after a .write() we can do a .tell() and it'll always be reasonable, but I'm unclear from reading the specification if that's a smart thing to rely on. This matches what we do on Windows and what Python 3 does for free, so let's just be consistent. Thanks to Yuya for the idea.
Sat, 06 Jul 2019 19:55:29 -0400 tweakdefaults: make hg resolve require --re-merge flag to re-merge
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 06 Jul 2019 19:55:29 -0400] rev 42561
tweakdefaults: make hg resolve require --re-merge flag to re-merge Pulkit suggested it in https://phab.mercurial-scm.org/D4379, and a discussion with Octobus people reminded me that people still use the error-prone default behavior of `hg resolve`. Differential Revision: https://phab.mercurial-scm.org/D6610
Thu, 04 Jul 2019 21:29:28 +0530 unshelve: rename _dounshelve() to dounshelve()
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 04 Jul 2019 21:29:28 +0530] rev 42560
unshelve: rename _dounshelve() to dounshelve() This is a follow-up patch to 3de4f17f4824. Differential Revision: https://phab.mercurial-scm.org/D6605
Mon, 01 Jul 2019 15:07:31 +0200 rust: remove Deref in favor of explicit methods
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 15:07:31 +0200] rev 42559
rust: remove Deref in favor of explicit methods Differential Revision: https://phab.mercurial-scm.org/D6593
Mon, 01 Jul 2019 10:53:36 +0200 rust: simplify overly complicated expression
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 10:53:36 +0200] rev 42558
rust: simplify overly complicated expression Differential Revision: https://phab.mercurial-scm.org/D6592
Mon, 01 Jul 2019 10:50:18 +0200 rust: run rfmt on all hg-core/hg-cpython code
Raphaël Gomès <rgomes@octobus.net> [Mon, 01 Jul 2019 10:50:18 +0200] rev 42557
rust: run rfmt on all hg-core/hg-cpython code Differential Revision: https://phab.mercurial-scm.org/D6591
Wed, 03 Jul 2019 10:06:39 +0800 move: --force flag forcibly moves, not copies stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:06:39 +0800] rev 42556
move: --force flag forcibly moves, not copies
Wed, 03 Jul 2019 10:01:51 +0800 copy: correct synopsis by making SOURCE a required argument stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 03 Jul 2019 10:01:51 +0800] rev 42555
copy: correct synopsis by making SOURCE a required argument
Tue, 02 Jul 2019 10:53:29 +0200 debugrevlog: fix average size computation for empty data (issue6167) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Jul 2019 10:53:29 +0200] rev 42554
debugrevlog: fix average size computation for empty data (issue6167) If the file has no full snapshot (eg: was always empty), `hg debugrevlog` would fails when trying to compute their average size.
Mon, 01 Jul 2019 16:25:51 -0700 changelog: fix handling of empty copy entries in changeset
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Jul 2019 16:25:51 -0700] rev 42553
changelog: fix handling of empty copy entries in changeset Before this patch, when an empty value was found in the changeset, we would get a ValueError, which would result in None being returned for addedfiles/removedfiles and p1copies/p2copies. That made 278dcb24e535 (copies: write empty entries in changeset when also writing to filelog, 2019-04-23) ineffective at helping the read path not look for copies in the filelogs. Differential Revision: https://phab.mercurial-scm.org/D6595
Sun, 30 Jun 2019 17:52:57 +0530 relnotes: document the new --force-close-branch flag
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 17:52:57 +0530] rev 42552
relnotes: document the new --force-close-branch flag Differential Revision: https://phab.mercurial-scm.org/D6590
Tue, 11 Jun 2019 20:53:14 +0300 py3: hack around inconsistency of type of name passed to DNSQuestion
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 11 Jun 2019 20:53:14 +0300] rev 42551
py3: hack around inconsistency of type of name passed to DNSQuestion I don't like this patch but this is the easiest way I could fix it. There are some callers which pass name which is bytes, some pass name which is str. I just encode() that if that's str. This does makes test-paths.t pass, but I am not confident whether the whole of zeroconf will work on py3 or not. Differential Revision: https://phab.mercurial-scm.org/D6511
(0) -30000 -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 +3000 tip