Fri, 27 Dec 2019 13:52:39 -0500 rebase: drop an unused variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:52:39 -0500] rev 43983
rebase: drop an unused variable assignment Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7746
Fri, 27 Dec 2019 13:50:53 -0500 polib: drop an unused local function
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:50:53 -0500] rev 43982
polib: drop an unused local function Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7745
Fri, 27 Dec 2019 13:47:17 -0500 perf: drop an unused variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:47:17 -0500] rev 43981
perf: drop an unused variable assignment Caught by PyCharm. A different formatter is created below in `_displaystats()`. Differential Revision: https://phab.mercurial-scm.org/D7744
Fri, 27 Dec 2019 13:45:05 -0500 perf: drop an unnecessary `pass`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:45:05 -0500] rev 43980
perf: drop an unnecessary `pass` Differential Revision: https://phab.mercurial-scm.org/D7743
Fri, 27 Dec 2019 13:42:52 -0500 perf: fix the time measurement for pathcopies relative to p2
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:42:52 -0500] rev 43979
perf: fix the time measurement for pathcopies relative to p2 PyCharm flagged this as unused. But it seems more likely that it was intended to reset the time for the p2 path. Differential Revision: https://phab.mercurial-scm.org/D7742
Fri, 27 Dec 2019 13:29:45 -0500 githelp: drop unused variable assignments
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:29:45 -0500] rev 43978
githelp: drop unused variable assignments Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7741
Fri, 27 Dec 2019 13:24:20 -0500 debug: drop unused variable assignments
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:24:20 -0500] rev 43977
debug: drop unused variable assignments Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7740
Fri, 27 Dec 2019 13:18:19 -0500 changegroup: drop an unused variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:18:19 -0500] rev 43976
changegroup: drop an unused variable assignment Caught by PyCharm. The variable is assigned again below before it is used. Differential Revision: https://phab.mercurial-scm.org/D7739
Fri, 27 Dec 2019 13:13:33 -0500 bugzilla: drop an unused variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:13:33 -0500] rev 43975
bugzilla: drop an unused variable assignment Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7738
Fri, 27 Dec 2019 13:11:22 -0500 ancestor: drop another unused variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:11:22 -0500] rev 43974
ancestor: drop another unused variable assignment Also caught by PyCharm. The only time this is used is immediately after another assignment below this. Differential Revision: https://phab.mercurial-scm.org/D7737
Fri, 27 Dec 2019 13:05:22 -0500 ancestor: drop an unused local variable assignment
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 13:05:22 -0500] rev 43973
ancestor: drop an unused local variable assignment Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7736
Fri, 27 Dec 2019 02:44:00 -0500 cleanup: drop unused import from pywatchman
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 02:44:00 -0500] rev 43972
cleanup: drop unused import from pywatchman Caught by PyCharm. Differential Revision: https://phab.mercurial-scm.org/D7735
Fri, 27 Dec 2019 02:05:01 -0500 narrow: move `testedwith` after module imports
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Dec 2019 02:05:01 -0500] rev 43971
narrow: move `testedwith` after module imports PyCharm flagged this as a PEP 8 violation, for module level imports not being at the top of the file. Differential Revision: https://phab.mercurial-scm.org/D7734
Thu, 26 Dec 2019 18:26:06 -0500 match: don't util.normpath() cwd
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Dec 2019 18:26:06 -0500] rev 43970
match: don't util.normpath() cwd The problem here is that `util.normpath()` calls `util.pconvert()`, which switches to Unix style separators. That results in two test failures like this since 5685ce2ea3bf: --- c:/Users/Matt/hg/tests/test-globalopts.t +++ c:/Users/Matt/hg/tests/test-globalopts.t.err @@ -89,7 +89,7 @@ [255] $ hg -R b ann a/a abort: a/a not under root '$TESTTMP/b' - (consider using '--cwd b') + (consider using '--cwd ..\$TESTTMP\b') [255] $ hg log abort: no repository found in '$TESTTMP' (.hg not found)! ERROR: test-globalopts.t output changed Martin originally had `os.path.normpath()` (which *would* work here too), but changed it during review. He didn't remember why he thought any form is needed here. Most uses simply pass '' or `repo.getcwd()`, so these should generally be in local format anyway. It seems better if `cwd` and `root` use consistent styles here. Differential Revision: https://phab.mercurial-scm.org/D7725
Thu, 26 Dec 2019 16:45:56 -0500 tests: convert the `root` arg of matchmod.match() to local path separators
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Dec 2019 16:45:56 -0500] rev 43969
tests: convert the `root` arg of matchmod.match() to local path separators This fixes tests that broke with 8b1a9ba375e5, complaining that "X not under root /repo". The vast majority of real uses are to pass `repo.root`, which is normalized by `wdirvfs.base` being set to the result of `os.path.realpath()`. Failure to convert looks like this: --- c:/Users/Matt/hg/tests/test-match.py.out +++ c:/Users/Matt/hg/tests/test-match.py.err @@ -0,0 +1,48 @@ +ERROR: testVisitchildrensetGlob (__main__.IncludeMatcherTests) + +Traceback (most recent call last): + File "c:\Users\Matt\hg\tests\test-match.py", line 180, in testVisitchildrensetGlob + m = matchmod.match(b'/repo', b'', include=[b'glob:dir/z*']) + File "c:\Users\Matt\hg\mercurial\match.py", line 271, in match + kindpats = normalize(include, b'glob', root, cwd, auditor, warn) + File "c:\Users\Matt\hg\mercurial\match.py", line 322, in _donormalize + pat = pathutil.canonpath(root, cwd, pat, auditor=auditor) + File "c:\Users\Matt\hg\mercurial\pathutil.py", line 251, in canonpath + _(b"%s not under root '%s'") % (myname, root), hint=hint +Abort: dir/z* not under root '/repo' +ERROR: testVisitdirGlob (__main__.IncludeMatcherTests) Differential Revision: https://phab.mercurial-scm.org/D7724
Fri, 27 Dec 2019 16:47:47 +0100 commitablectx: fix the default phase
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 27 Dec 2019 16:47:47 +0100] rev 43968
commitablectx: fix the default phase The code was ignoring the config option. Since the config option will control the actual phase of the committed result, we better take it in account early. Differential Revision: https://phab.mercurial-scm.org/D7726
Wed, 18 Dec 2019 14:07:58 -0800 fix: fix handling of merge commits by using overlayworkingctx
Kyle Lippincott <spectral@google.com> [Wed, 18 Dec 2019 14:07:58 -0800] rev 43967
fix: fix handling of merge commits by using overlayworkingctx Most of this code was conceptually copied from what rebase does, with one small difference: hgext.rebaserev.rebase uses branchmerge=True, while I had to use branchmerge=False, or else it got really confused about updating to the same revision in some situations. I believe that the difference is that rebase is always dealing with *some* form of update - it never gets to mergemod.update if the source and destination are the same, while we can encounter that situation with fix. This may imply that this code has some issues with named branches that should be investigated. Differential Revision: https://phab.mercurial-scm.org/D7703
Mon, 23 Dec 2019 10:02:50 -0800 rust-index: add a struct wrapping the C index
Georges Racinet <georges.racinet@octobus.net> [Mon, 23 Dec 2019 10:02:50 -0800] rev 43966
rust-index: add a struct wrapping the C index Implementing the full index logic in one go is journey larger than we would like. To achieve a smoother transition, we start with a simple Rust wrapper that delegates allwork to the current C implementation. Once we will have a fully working index object in Rust, we can easily start using more and more Rust Code with it. The object in this patch is functional and tested. However, multiple of the currently existing rust (in the `hg-cpython` crate) requires a `Graph`. Right now we build this `Graph` (as cindex::Index) using the C index passed as a PyObject. They will have to be updated to be made compatible. Differential Revision: https://phab.mercurial-scm.org/D7655
Thu, 12 Dec 2019 03:46:47 +0100 rust-index: add a `inner` method to the Index struct
Georges Racinet <georges.racinet@octobus.net> [Thu, 12 Dec 2019 03:46:47 +0100] rev 43965
rust-index: add a `inner` method to the Index struct We are about to introduce a Rust wrapper to the C index. It will be exposed as a Python object. As a start all call will be forwarded to an internal index object (as used now). For this forwarding to works, we need to access that index object (from the C extensions). We adds a method doing to on the existing `Index` rust struct. Differential Revision: https://phab.mercurial-scm.org/D7654
Wed, 27 Nov 2019 17:59:58 +0100 revlog: made C Capsule an array of function pointers
Georges Racinet <georges.racinet@octobus.net> [Wed, 27 Nov 2019 17:59:58 +0100] rev 43964
revlog: made C Capsule an array of function pointers Although it's perfectly valid to put a function pointer in a capsule, as we've been doing since the start of rust/hg-cpython, an array of function pointers has several advantages: - it can hold several functions. That's our main motivation here. We plan to expose index_length() and index_node(), which will be needed for a Rust implementation of nodemap. - it could also have data - (probably minor in the case of Mercurial) proper support for architectures for which data and code pointers don't have the same size. Differential Revision: https://phab.mercurial-scm.org/D7543
Sun, 22 Dec 2019 23:09:37 -0500 lfs: fix a discrepancy with a function wanting a filelog, but calling it rlog
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 23:09:37 -0500] rev 43963
lfs: fix a discrepancy with a function wanting a filelog, but calling it rlog This conceptually broke in 1541e1a8e87d when the filelog isa revlog relationship was changed to containment of the revlog. It was made more obvious in 62a532045e71 and related API simplification. It's resolved in favor of passing a revlog because the revlog verification code doesn't have a reference to a filelog. Differential Revision: https://phab.mercurial-scm.org/D7711
Sun, 22 Dec 2019 16:36:09 -0500 revlog: split the content verification of a node into a separate method
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 16:36:09 -0500] rev 43962
revlog: split the content verification of a node into a separate method This will be used by LFS to tune what is skipped. In the future, this could also be used by LFS to indicate which nodes tagged with `skipread` are simply in need of a blob fetch, so that they can be done in a batch later. (Currently, `skipread` also indicates censored data and errors.) Additionally, it could be used to cache the sha1 hash value for each blob so that large blobs don't need to be re-read and re-hashed if they are used by multiple nodes. Differential Revision: https://phab.mercurial-scm.org/D7710
Sun, 22 Dec 2019 00:47:33 -0500 verify: update comment to say that lfs doesn't need fulltext to check renames
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 00:47:33 -0500] rev 43961
verify: update comment to say that lfs doesn't need fulltext to check renames The reason is that `filelog.renamed()` indirectly calls `filelog.revision()`, which is what accesses the full text. However, LFS wraps `filelog.renamed()` and completely handles the case where an LFS blob is in play by using rawdata. I've got a test to demonstrate that this is the case, and prevent regressions. But the `skipread` flag is set on all lfs revisions when using `--no-lfs`, regardless of whether or not the blobs are local. Just above this, that flag is consulted, causing the rename checks to be skipped. That will need to be loosened up first. Differential Revision: https://phab.mercurial-scm.org/D7709
Wed, 18 Dec 2019 13:30:48 -0800 resourceutil: use `from importlib import resources`
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Dec 2019 13:30:48 -0800] rev 43960
resourceutil: use `from importlib import resources` Without this patch, we get the following error from when trying to run hg with PyOxidizer: module 'importlib' has no attribute 'resources' I don't know what why that happens, but `from importlib import resources` is the form I would prefer anyway, so let's use that now that the impoort-checker has been fixed. Differential Revision: https://phab.mercurial-scm.org/D7701
Wed, 18 Dec 2019 13:39:44 -0800 import-checker: allow all absolute imports of stdlib modules
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Dec 2019 13:39:44 -0800] rev 43959
import-checker: allow all absolute imports of stdlib modules Before this patch, we didn't allow imports like from importlib import resources (That's the reason I used `import importlib.resources` in D7629.) I think that form is still an absolute import, so I don't think we forbade on purpose. Differential Revision: https://phab.mercurial-scm.org/D7700
Tue, 17 Dec 2019 22:36:40 -0500 help: drop a reference to Windows 9x
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:36:40 -0500] rev 43958
help: drop a reference to Windows 9x Differential Revision: https://phab.mercurial-scm.org/D7694
Tue, 17 Dec 2019 22:33:37 -0500 help: clarify that the Windows registry key for hgrc files is systemwide
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:33:37 -0500] rev 43957
help: clarify that the Windows registry key for hgrc files is systemwide Since there's no version or path info here to distinguish between installations, it is effectively systemwide (unless splitting hairs about the WoW64 registry redirection). Differential Revision: https://phab.mercurial-scm.org/D7693
Tue, 17 Dec 2019 22:08:07 -0500 windows: add a global equivalent to /etc/mercurial for *.rc processing
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:08:07 -0500] rev 43956
windows: add a global equivalent to /etc/mercurial for *.rc processing This follows the Unix model of processing this directory immediately after <internal>/*.rc, and prior to the installation relative files. Since the Unix processing supports both a directory and a file (the former overriding the latter), and since %HOME% supports both `*.ini` and `.hgrc` (again, the former overriding the latter), this does too. The Unix file doesn't have a `.` prefix, so it's not used here either. Note that this is the opposite order of processing the exe relative paths. But since it's in agreement with Unix, %HOME% and %USERPROFILE%, it seems reasonable to ignore that. Maybe we can change that and take a BC, because that's something the installer should be controlling, and I can't imagine people having both paths *and* conflicting settings. Differential Revision: https://phab.mercurial-scm.org/D7692
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 tip