Thu, 16 Feb 2023 14:43:46 +0000 rhg: nicer error message
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:43:46 +0000] rev 50094
rhg: nicer error message
Tue, 14 Feb 2023 12:40:59 -0500 typing: add type hints to argument checking functions in cmdutil
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 12:40:59 -0500] rev 50093
typing: add type hints to argument checking functions in cmdutil These might be surprising, since they can take strings instead of bytes. The way `AnyStr` works is that it must be all bytes or all str for any given invocation. The wildcard here will be the `opts` that get passed in- if the type is unknown and defaults to `Any`, there's no enforcement that the dict key type matches the additional args. But a lot of uses should be using `**opts` from the command method, which has a str key. The uses of these methods in this module are now typed because their internals force a specific type, and it can't just be inferred from the caller.
Fri, 17 Feb 2023 16:45:36 +0100 setup: further improve the error path for version retrieval stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 16:45:36 +0100] rev 50092
setup: further improve the error path for version retrieval This is a new take at the problem that 8d390a13474d tried to tackle. There was two issues after that previous improvement: - the 0.0+ version could survive a bit too long and reaching the installer version and staying there. - multiple use case where still failing. So the new code is better at: - always succeeding when running `make local` so that we can bootstrap a local version - no using that fallback outside of `make local` to avoid distribution of version with the buggy version number. The setup.py is a gigantic pile of spaghetti code, to the point where pastafarian pilgrim started knocking at its core. However I refrained from cleaning that up since the more to a `setup.cfg` means this code should be deleted soon™.
Tue, 14 Feb 2023 15:45:26 -0500 tag: move the prohibition of tagging the `null` rev up to the `wdir()` check
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 15:45:26 -0500] rev 50091
tag: move the prohibition of tagging the `null` rev up to the `wdir()` check It makes sense to do these together, and avoid another revision lookup.
Fri, 17 Feb 2023 17:04:41 +0100 branching: merge with default
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 17:04:41 +0100] rev 50090
branching: merge with default the first part of the fix is there
Fri, 17 Feb 2023 14:00:39 +0100 dirstate: handle missing backup file on restoration stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 14:00:39 +0100] rev 50089
dirstate: handle missing backup file on restoration This is the stable counter part to e358f6e0e50e. Since 6.4 will stop writing undo.dirstate in some case (actually… at all), a transaction created with 6.4 and recover/rolledback with 6.3 need to work to a certain degreee. This changeset add the necessary bits so that we don't get a traceback from 6..3 in this cases.
Fri, 27 Jan 2023 17:30:51 +0100 tests: remove unnecessary --traceback argument
Dan Villiom Podlaski Christiansen <dan.villiom.podlaski.christiansen@sallinggroup.com> [Fri, 27 Jan 2023 17:30:51 +0100] rev 50088
tests: remove unnecessary --traceback argument
Tue, 14 Feb 2023 11:56:02 -0500 tag: disallow tagging the working directory stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 11:56:02 -0500] rev 50087
tag: disallow tagging the working directory It's kinda silly, but a clear error message is better than a stacktrace about subscripting `None` when trying to generate the default commit message. I'm surprised that `.revsingle(..).node()` returns None instead of `nodemod.wdirid`, but now there's a test to catch if this changes.
Thu, 16 Feb 2023 04:49:35 +0100 dirstate: remove the dedicated backup logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:49:35 +0100] rev 50086
dirstate: remove the dedicated backup logic When alone, the dirstate can now take care of its commit/rollback pattern itself. When in a transaction, the transaction deal with commit/rollback pattern quite fine. Why did you have a dedicated backup logic?
Thu, 16 Feb 2023 04:02:36 +0100 localrepo: stop doing special dirstate backup at transaction open
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:02:36 +0100] rev 50085
localrepo: stop doing special dirstate backup at transaction open Since the dirstate writes are already managed by the transaction, we already do a backup of the dirstate when necessary (and even trigger one to keep `hg rollback` happy). We needs some special code to deal with the initial empty checkout, but it is not too complicated. Managing variable filename (as dirstate-v2 uses) at the "journalfile" level, is complex and fragile (which is consistent with the fact these files are not journal…). If we no longer do it, our life is significantly simpler. In some sense, we apply the xkcd-1134¹ solution to our savebackup/restorebackup problem. [1] https://xkcd.com/1134/ (the change to test-hardlink are expect as decreasing the number of duplicated backup drive the hardlink count down)
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip