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
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
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
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
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
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 30 May 2020 11:36:30 -0400] rev 44904
rust: add a pointer for profiling to the README
As figuring out how to get useful profiles is not obvious.
Differential Revision: https://phab.mercurial-scm.org/D8603
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 30 May 2020 10:28:46 -0400] rev 44903
rust: update the mention of hgcli in rust/README.rst
This may not be exactly right, but it's better than before.
Differential Revision: https://phab.mercurial-scm.org/D8602
Manuel Jacob <me@manueljacob.de> [Mon, 01 Jun 2020 15:22:31 +0200] rev 44902
sslutil: fix comment to use inclusive or instead of exclusive or
The incorrect "either" was introduced by one of my recent patches.
Manuel Jacob <me@manueljacob.de> [Mon, 01 Jun 2020 14:34:22 +0200] rev 44901
sslutil: propagate return value ssl.PROTOCOL_SSLv23 from protocolsettings()
Also, protocolsettings() was renamed to commonssloptions() to reflect that
only the options are returned.