Wed, 03 Jun 2020 12:04:38 -0700 context: fix creation of ProgrammingError to not use non-existent field
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Jun 2020 12:04:38 -0700] rev 44934
context: fix creation of ProgrammingError to not use non-existent field Differential Revision: https://phab.mercurial-scm.org/D8606
Wed, 03 Jun 2020 22:07:26 -0700 help: explain in `hg help flags` that unambiguous prefixes are allowed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Jun 2020 22:07:26 -0700] rev 44933
help: explain in `hg help flags` that unambiguous prefixes are allowed I used `hg commit --amend` as an example because that's the most frequently used flag I could think of that doesn't yet have a short form. Differential Revision: https://phab.mercurial-scm.org/D8607
Wed, 03 Jun 2020 11:28:57 -0400 git: add coverage for manifest.diff() so we don't regress
Augie Fackler <augie@google.com> [Wed, 03 Jun 2020 11:28:57 -0400] rev 44932
git: add coverage for manifest.diff() so we don't regress
Mon, 01 Jun 2020 11:12:25 -0400 git: implement diff manifest method
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Mon, 01 Jun 2020 11:12:25 -0400] rev 44931
git: implement diff manifest method This makes 'hg diff' work.
Mon, 01 Jun 2020 09:49:47 -0400 git: properly visit child tree objects when resolving a path
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Mon, 01 Jun 2020 09:49:47 -0400] rev 44930
git: properly visit child tree objects when resolving a path
Mon, 01 Jun 2020 09:40:18 -0400 git: don't yield paths for directories when walking
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Mon, 01 Jun 2020 09:40:18 -0400] rev 44929
git: don't yield paths for directories when walking
Mon, 01 Jun 2020 09:22:53 -0400 git: correctly check for type of object when walking
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Mon, 01 Jun 2020 09:22:53 -0400] rev 44928
git: correctly check for type of object when walking
Mon, 01 Jun 2020 08:59:48 -0400 git: implement stub prefetch_parents dirstate method
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> [Mon, 01 Jun 2020 08:59:48 -0400] rev 44927
git: implement stub prefetch_parents dirstate method A recent change (35b255e474d9) introduced this new required dirstate method but didn't update the git extension.
Mon, 25 May 2020 23:06:50 +0900 rust: leverage .expect() in place of .unwrap() + inline comment
Yuya Nishihara <yuya@tcha.org> [Mon, 25 May 2020 23:06:50 +0900] rev 44926
rust: leverage .expect() in place of .unwrap() + inline comment For a better error indication in case we made a mistake.
Mon, 25 May 2020 23:02:07 +0900 rust: fix false comment about mpsc::Sender
Yuya Nishihara <yuya@tcha.org> [Mon, 25 May 2020 23:02:07 +0900] rev 44925
rust: fix false comment about mpsc::Sender We need Sync to share the Sender reference across threads.
Tue, 09 Jun 2020 05:24:45 +0200 resourceutil: fix location of line comments stable
Manuel Jacob <me@manueljacob.de> [Tue, 09 Jun 2020 05:24:45 +0200] rev 44924
resourceutil: fix location of line comments These comments slipped out of position when the sources where formatted with black in 2372284d9457.
Thu, 30 Apr 2020 00:33:00 -0400 rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:33:00 -0400] rev 44923
rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291) See 56d3e0b499df for the source of adding originalwd to the list of things that cause wdir to be updated. That change didn't come with tests, and attempts to recreate the scenario described have thus far failed. Differential Revision: https://phab.mercurial-scm.org/D8489
Thu, 30 Apr 2020 00:12:11 -0400 tests: show that rebase --dry-run and --confirm wipeout uncommitted changes stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:12:11 -0400] rev 44922
tests: show that rebase --dry-run and --confirm wipeout uncommitted changes It looks like the carnage is limited to rebasing something that is not an ancestor of wdir(), as both of these abort in a preflight check for that case with a dirty working directory. Differential Revision: https://phab.mercurial-scm.org/D8488
Sat, 06 Jun 2020 00:51:36 +0530 Added signature for changeset 065704cbdbdb stable
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:36 +0530] rev 44921
Added signature for changeset 065704cbdbdb
Sat, 06 Jun 2020 00:51:28 +0530 Added tag 5.4.1 for changeset 065704cbdbdb stable
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:28 +0530] rev 44920
Added tag 5.4.1 for changeset 065704cbdbdb
Fri, 05 Jun 2020 06:40:15 +0200 py3: update comment to account for Python 2 and Python 3 differences stable 5.4.1
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 06:40:15 +0200] rev 44919
py3: update comment to account for Python 2 and Python 3 differences
Fri, 05 Jun 2020 07:20:52 +0200 py3: add warning about buffering behavior of pycompat.{stdout,stderr} stable
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 07:20:52 +0200] rev 44918
py3: add warning about buffering behavior of pycompat.{stdout,stderr}
Fri, 05 Jun 2020 04:10:37 +0200 tests: fix indentation stable
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 04:10:37 +0200] rev 44917
tests: fix indentation
Wed, 03 Jun 2020 19:20:18 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Wed, 03 Jun 2020 19:20:18 +0900] rev 44916
merge with stable
Tue, 02 Jun 2020 20:40:06 +0900 graft: fix --base value to be saved in state file stable
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jun 2020 20:40:06 +0900] rev 44915
graft: fix --base value to be saved in state file 'True' just works because it is treated as an integer revision '1' and only the truthiness of the basectx is important. If multiple source revisions were supported with --base, the resumed graft operation would go wrong.
Sat, 16 May 2020 20:38:53 +0200 flags: also test merge with executable bit removed stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:53 +0200] rev 44914
flags: also test merge with executable bit removed This might catch more bug in the future. Differential Revision: https://phab.mercurial-scm.org/D8536
Sat, 16 May 2020 20:38:42 +0200 flags: also test the removal of the exec flag stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:42 +0200] rev 44913
flags: also test the removal of the exec flag Differential Revision: https://phab.mercurial-scm.org/D8535
Sat, 16 May 2020 20:38:31 +0200 flags: read flag from dirstate/disk for workingcopyctx (issue5743) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:31 +0200] rev 44912
flags: read flag from dirstate/disk for workingcopyctx (issue5743) In 491855ea9d62, various piece of code are moved from committablectx to workingctx. The reason given is "These read from the dirstate, so they shouldn't be used in other subclasses." At least for `flags` this change introduce a bug, because the value flags end up being read from `_manifest` disregarding the actual state in the working copy (ie: on disk). When merging exec flag change with renames, this means a new files (the local content, renamed) is properly written on disk, with the right flags, but the flags part is later ignored when actually reading flags during merge. It is not clear to me why the `flags` function was moved, because the code does not actually hit the dirstate (the reason given in the changeset description). So I am moving it back to were it comes from and we use a simpler version of that code (that hit the dirstate everytime) in workingcopyctx. This fix the last know bug with merging rename and executable byte changes. Other similar bug might be lurking in 491855ea9d62, but I have not investigated them. Differential Revision: https://phab.mercurial-scm.org/D8534
Sat, 16 May 2020 20:38:19 +0200 flags: actually merge flags in simplemerge stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:19 +0200] rev 44911
flags: actually merge flags in simplemerge Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when rename are involved. exec flag change are now properly merged (when merged from the rename side). Another bug is affecting this when merging from the side without the rename. Differential Revision: https://phab.mercurial-scm.org/D8533
Sat, 16 May 2020 20:38:07 +0200 flags: add a test for merging exec flag change with rename and file change stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:07 +0200] rev 44910
flags: add a test for merging exec flag change with rename and file change Changing the file activate other code path that also have bugs… There are two distinct bugs depending of which side of the merge you stand on. They both leading to exec flag loss. We add tests for both, the fix are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8532
Sat, 16 May 2020 20:37:56 +0200 flags: account for flag change when tracking rename relevant to merge stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:56 +0200] rev 44909
flags: account for flag change when tracking rename relevant to merge There are some logic filtering rename to the one relevant to the merge. That logic was oblivious of flag change, leading to exec flag being dropped when merged with a renamed. There are two others bugs affecting this scenario. This patch fix the was where there is not modification involved except for the flag change. Fixes for the other bug are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8531
Sat, 16 May 2020 20:37:44 +0200 flags: also test merging a rename with and exec flag change stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:44 +0200] rev 44908
flags: also test merging a rename with and exec flag change This case is currently buggy and was not tested. This is probably a quite old regression. The next changeset fix this case. Move exec+rename related bug will gain a test later. To highlight the expected behavior the currently missing line are marked with (false !) and the bad one with (true !) note: we should probably gain explicit "test bool" for this usecases. Differential Revision: https://phab.mercurial-scm.org/D8530
Sat, 16 May 2020 20:37:33 +0200 flags: introduce explicit testing for merging change to exec flag stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:33 +0200] rev 44907
flags: introduce explicit testing for merging change to exec flag It turns out that we do not seems to test the simple case for merging exec flag changes. More advanced case are test (merging exec flag without a common ancestors, merging with a symlink, etc…) but not the basic. We are about introduce various fixes to merging flag change across renames, having the most basic case tested first seems useful. note: We are only testing "adding" an exec flag here, not removing it. We introduce basic test on stable and will consolidate them on default. Differential Revision: https://phab.mercurial-scm.org/D8529
Tue, 26 May 2020 11:14:07 -0400 graft-state: save --base in graft's state, fixing bug with graft --continue stable
Charles Chamberlain <cchamberlain@janestreet.com> [Tue, 26 May 2020 11:14:07 -0400] rev 44906
graft-state: save --base in graft's state, fixing bug with graft --continue Without this change, running graft --continue after grafting a merge commit using --base (and encountering conflicts) will output "skipping ungraftable merge revision" even though we specified a base in the initial graft command. Graft's improve behaviour is reflected in test-graft.t. Differential Revision: https://phab.mercurial-scm.org/D8578
Sat, 30 May 2020 12:36:00 -0400 relnotes: advertize the possibility to use rust
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 30 May 2020 12:36:00 -0400] rev 44905
relnotes: advertize the possibility to use rust I think the rust work may have been mentioned in the release notes, but if so only in passing, and not as an invitation to try it out. I think the next version is a decent time to do this, because the rust doesn't come with performance regressions AFAIK, speeds up status noticeably when it applies, which is the case for most invocations of status, and doesn't have the undesirable restriction of regex around empty patterns anymore. I am cheating a bit, because I'm giving numbers for `hg status` in mozilla-central, but they have one hgignore pattern that uses lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took out as it would cause a fallback to python when unknown files are requested. But it seems that they could express their hgignore differently if they were so inclined. Not sure if there are limitation other than linux-only that I am not thinking of but would be worth mentioning upfront, to avoid disappointing users? Differential Revision: https://phab.mercurial-scm.org/D8604
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip