Tue, 17 May 2022 00:09:51 +0100 ci: do not trigger phabricator for merge-request stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 17 May 2022 00:09:51 +0100] rev 48865
ci: do not trigger phabricator for merge-request The fast the phabricator steps has a `rules` entry makes it selected for the special `merge_requests` pipelines. The other ones behave as default and are not selected tot the mrege_request pipelines. This result in a second pipeline to be created, with only the phabricator pipeline in it. Which usually succeed fast (since there is nothing to do). This is harmful as this create a false sense of "the series is passing" and Gitlab will use this simplistic pipeline for validation. By explicitly preventing the pipeline to be created in the merge-request case, we prevent this situation to happens Note that the job will be dropped (alonside phabricator) in the next two weeks anyway.
Wed, 11 May 2022 17:56:29 -0700 amend: stop specifying matcher, get all copies in wctx stable
Kyle Lippincott <spectral@google.com> [Wed, 11 May 2022 17:56:29 -0700] rev 48864
amend: stop specifying matcher, get all copies in wctx When we're recreating the commit that we'll be committing, we don't want to filter our copy information based on just the *new* [versions of the] files we're amending. The test has an example of this case, but for clarity, the situation is: ``` $ hg cp src dst && hg commit <do some work> $ hg amend some_unrelated_file.txt $ hg status --copies A dst A some_unrelated_file.txt ``` What *should* happen is that `dst` should remain marked as a copy of `src`, but this did not previously happen. `matcher` here only includes the files that were specified on the commandline, so it only gets the copy information (if any, in this example there's not) for `some_unrelated_file.txt`. When it goes to apply the memctx to actually create the commit, the file copy information is incomplete and loses the information for the files that shouldn't have been affected at all by the amend. Differential Revision: https://phab.mercurial-scm.org/D12625
Wed, 11 May 2022 17:56:10 -0700 amend: add test showing poor behavior when copies are involved stable
Kyle Lippincott <spectral@google.com> [Wed, 11 May 2022 17:56:10 -0700] rev 48863
amend: add test showing poor behavior when copies are involved Differential Revision: https://phab.mercurial-scm.org/D12624
Wed, 04 May 2022 17:40:23 +0100 censor: fix [hg update] away from a revision with censored files stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Wed, 04 May 2022 17:40:23 +0100] rev 48862
censor: fix [hg update] away from a revision with censored files Differential Revision: https://phab.mercurial-scm.org/D12604
Fri, 22 Apr 2022 14:39:00 +0100 censor: demonstrate a bug stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 22 Apr 2022 14:39:00 +0100] rev 48861
censor: demonstrate a bug Differential Revision: https://phab.mercurial-scm.org/D12584
Wed, 04 May 2022 18:04:46 +0200 Added signature for changeset 0ddd5e1f5f67 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:04:46 +0200] rev 48860
Added signature for changeset 0ddd5e1f5f67
Wed, 04 May 2022 18:04:06 +0200 Added tag 6.1.2 for changeset 0ddd5e1f5f67 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:04:06 +0200] rev 48859
Added tag 6.1.2 for changeset 0ddd5e1f5f67
Wed, 04 May 2022 18:00:01 +0200 ci: remove py2-rust support stable 6.1.2
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:00:01 +0200] rev 48858
ci: remove py2-rust support Nobody cares about this very narrow usecase, and py2 support is over by July 1st. This helps with the CI load, and removes some flakiness.
Wed, 04 May 2022 17:45:20 +0200 relnotes: add release notes for 6.1.2 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 17:45:20 +0200] rev 48857
relnotes: add release notes for 6.1.2
Tue, 03 May 2022 12:41:21 +0200 docs: use proper rst markup for preformatted blocks stable
Mads Kiilerich <mads@kiilerich.com> [Tue, 03 May 2022 12:41:21 +0200] rev 48856
docs: use proper rst markup for preformatted blocks The multiple lines were re-flowed to a single line, both in man page and html.
Wed, 04 May 2022 15:49:20 +0200 test-dirstate: print something when the check is skipped stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 15:49:20 +0200] rev 48855
test-dirstate: print something when the check is skipped This makes a programming error obvious in cases when it should not be skipped Differential Revision: https://phab.mercurial-scm.org/D12602
Wed, 04 May 2022 15:48:13 +0200 test-dirstate: fix detection of Rust environment variable stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 15:48:13 +0200] rev 48854
test-dirstate: fix detection of Rust environment variable The Rust path never actually worked. This change also improves clarity of the comment. The next change will ensure we print something when this check fails. Differential Revision: https://phab.mercurial-scm.org/D12601
Thu, 28 Apr 2022 17:15:35 +0200 rust-dirstate-v2: fix the unused bytes counter when rewriting the dirstate stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 17:15:35 +0200] rev 48853
rust-dirstate-v2: fix the unused bytes counter when rewriting the dirstate As per the previous patch, the counter was incorrectly carried over from the old docket when it should be reset for a complete rewrite. Differential Revision: https://phab.mercurial-scm.org/D12594
Thu, 28 Apr 2022 17:11:51 +0200 rust-dirstate-v2: show `unused_bytes` counter is not reset on total rewrite stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 17:11:51 +0200] rev 48852
rust-dirstate-v2: show `unused_bytes` counter is not reset on total rewrite This was picked up by @aalekseyev when doing unrelated debugging. The Rust implementation was never resetting this counter, so a brand new file would carry over the old counter. As I write this, my counter is a supposed 7389089 unused bytes for a total of 170978 bytes in the data file. Feel free to post your own high score. Differential Revision: https://phab.mercurial-scm.org/D12593
Thu, 28 Apr 2022 16:24:55 +0200 test-dirstate: use new `--docket` flag to get the data uuid stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 16:24:55 +0200] rev 48851
test-dirstate: use new `--docket` flag to get the data uuid This is more robust. Differential Revision: https://phab.mercurial-scm.org/D12592
Thu, 28 Apr 2022 15:22:08 +0200 debugcommands: remove `debugdirstateignorepatternhash` stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 15:22:08 +0200] rev 48850
debugcommands: remove `debugdirstateignorepatternhash` This is replaced by the more complete `--docket` option to `debugstate`. Differential Revision: https://phab.mercurial-scm.org/D12591
Thu, 28 Apr 2022 15:19:19 +0200 dirstate-v2: add flag to `debugstate` to print docket information stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 15:19:19 +0200] rev 48849
dirstate-v2: add flag to `debugstate` to print docket information This is useful information that we don't easily have access to currently, unless you speak fluent xxd. This replaces `debugdirstateignorepatternshash`, which I'll remove in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D12590
Mon, 02 May 2022 22:04:59 -0400 doc: use an absolute path in sys.path to work around a python DLL loading bug stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 02 May 2022 22:04:59 -0400] rev 48848
doc: use an absolute path in sys.path to work around a python DLL loading bug This bug[1] was causing the zstd entry under "Available Compression Engines" to be omitted from the documentation for some versions of python3. I could upgrade, but past upgrades have broken venvs and clobbered installed packages. It's a trivial workaround, so there's no sense in leaving this subtle issue. It was flushed out by changing the module policy here from 'allow' to 'c', and seeing this error: ImportError: DLL load failed while importing parsers: The parameter is incorrect. [1] https://github.com/python/cpython/issues/87271 Differential Revision: https://phab.mercurial-scm.org/D12599
Mon, 25 Apr 2022 16:45:03 +0200 rhg: fix dirstate-v2 data file removal system stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 25 Apr 2022 16:45:03 +0200] rev 48847
rhg: fix dirstate-v2 data file removal system In D12581 I introduced logic to remove the previous dirstate-v2 data file after a new one is created (and its corresponding docket), but the logic was flawed. I fixed it and made it simpler to understand by gather all logic in a single expression. Differential Revision: https://phab.mercurial-scm.org/D12586
Tue, 19 Apr 2022 12:27:40 +0200 rhg: use `Command::exec` instead of `Command::status` stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 19 Apr 2022 12:27:40 +0200] rev 48846
rhg: use `Command::exec` instead of `Command::status` `rhg` is supposed to be a transparent executable, using a subprocess defeats that purpose. See inline comments for more details. This also introduces the `which` crate to check if the fallback executable actually exists to help debugging (plain `execve` doesn't give much information). The error code 253 is used to signify that the fallback is not found, but may mean in the future that it is otherwise invalid if we start being more specific. Differential Revision: https://phab.mercurial-scm.org/D12578
Wed, 27 Apr 2022 15:47:57 +0200 commit: don't use hard-coded `.hg/last-message.txt` path in error message stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Apr 2022 15:47:57 +0200] rev 48845
commit: don't use hard-coded `.hg/last-message.txt` path in error message Whoever wrote D8463 just used a hard-coded path to `.hg/last-message.text` instead of using the relative path that was already available in the `msgfn` variable (and used just a few lines up in related message). Let's fix that. Differential Revision: https://phab.mercurial-scm.org/D12585
Thu, 21 Apr 2022 15:10:57 +0200 rust-dirstate-v2: clean up previous data file after the docket is written stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Apr 2022 15:10:57 +0200] rev 48844
rust-dirstate-v2: clean up previous data file after the docket is written This was overlooked before and caused many data files to keep living forever. We could potentially consider adding a random cleanup of them in case they slipped through one day. Differential Revision: https://phab.mercurial-scm.org/D12581
Thu, 21 Apr 2022 14:47:13 +0200 rust-dirstate-v2: save proper data size if no new data on append stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Apr 2022 14:47:13 +0200] rev 48843
rust-dirstate-v2: save proper data size if no new data on append This is currently only triggered with the tests ran with `--rhg` without `--rust`, by "luck", there probably always was something to write, like an mtime when also using Rust extensions alongside `rhg`. Differential Revision: https://phab.mercurial-scm.org/D12580
Wed, 13 Apr 2022 14:46:22 -0400 procutil: avoid `+= None` when writing to full std{err,out} descriptor on py3 stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 13 Apr 2022 14:46:22 -0400] rev 48842
procutil: avoid `+= None` when writing to full std{err,out} descriptor on py3 The write function returns `None` if there was no room to write the given data[1]. I don't like that this is effectively an infinite loop if there's never any progress emptying the underlying buffer, but we're no worse off than before, and it fixes random stacktrace popups seen in the py3 build of TortoiseHg. [1] https://docs.python.org/3/library/io.html#io.RawIOBase.write Differential Revision: https://phab.mercurial-scm.org/D12555
Mon, 18 Apr 2022 20:45:38 -0700 amend: don't remove unselected removals from memctx stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Apr 2022 20:45:38 -0700] rev 48841
amend: don't remove unselected removals from memctx When there are removed files in the working copy and they are not selected to be amended into the parent, the `filectxfn` we create for the `memctx` would still return `None` before this patch. That's clearly incorrect; we should return the `filectx` from the unamended commit. Somehow it seems to not matter much except for the case with copies stored in changesets. Thanks to Kyle Lippincott for doing all the debugging and identifying the fix for this issue. Differential Revision: https://phab.mercurial-scm.org/D12573
Mon, 18 Apr 2022 20:39:31 -0700 tests: demonstrate crash on partial amend with copies in changesets stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Apr 2022 20:39:31 -0700] rev 48840
tests: demonstrate crash on partial amend with copies in changesets See the fix in the next patch for explanation. Differential Revision: https://phab.mercurial-scm.org/D12572
Wed, 13 Apr 2022 12:14:17 -0700 rebase: while rewriting desc hashes, ignore ambiguous prefix "hashes" stable
Kyle Lippincott <spectral@google.com> [Wed, 13 Apr 2022 12:14:17 -0700] rev 48839
rebase: while rewriting desc hashes, ignore ambiguous prefix "hashes" If a repo is sufficiently large, a six digit number "hash prefix" can somewhat easily reference an ambiguous hash prefix. Differential Revision: https://phab.mercurial-scm.org/D12552
Wed, 13 Apr 2022 13:15:33 -0700 tests: add test demonstrating issue with ambiguous has prefixes during rebase stable
Kyle Lippincott <spectral@google.com> [Wed, 13 Apr 2022 13:15:33 -0700] rev 48838
tests: add test demonstrating issue with ambiguous has prefixes during rebase Differential Revision: https://phab.mercurial-scm.org/D12551
Thu, 07 Apr 2022 15:53:48 +0200 help: set the large-file-limit to 10MB stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Apr 2022 15:53:48 +0200] rev 48837
help: set the large-file-limit to 10MB This is a minor increase (5%) and makes the doc much clearer. Differential Revision: https://phab.mercurial-scm.org/D12484
Thu, 07 Apr 2022 15:46:07 +0200 help: clarify the unit of `ui.large-file-limit` config stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Apr 2022 15:46:07 +0200] rev 48836
help: clarify the unit of `ui.large-file-limit` config Its might be a bit confusing, especially since `large-file.min-size` uses MB. Differential Revision: https://phab.mercurial-scm.org/D12483
Wed, 06 Apr 2022 18:39:15 +0200 debuglock: ignore ENOENT error when unlocking stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Apr 2022 18:39:15 +0200] rev 48835
debuglock: ignore ENOENT error when unlocking This is consistent with the main `lock.release` code. Differential Revision: https://phab.mercurial-scm.org/D12481
Wed, 06 Apr 2022 18:50:20 +0200 run-tests: introduce "forward-slash" version of everything on windows stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Apr 2022 18:50:20 +0200] rev 48834
run-tests: introduce "forward-slash" version of everything on windows This should be useful for some shell invocation. Differential Revision: https://phab.mercurial-scm.org/D12480
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 tip