Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 09:57:29 -0700] rev 45576
merge: add a higher-level update() for the common `hg update` use case
This is different from the `update()` function that I just made
private. The new function is specifically for the normal `hg update`
use case. It doesn't do a merge and it doesn't do a clean (forced)
update.
Differential Revision: https://phab.mercurial-scm.org/D9066
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:35 +0200] rev 45575
sidedata: simply read p2copies files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:16 +0200] rev 45574
sidedata: simply read p1copies files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:16:01 +0200] rev 45573
sidedata: simply read removed files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:15:46 +0200] rev 45572
sidedata: simply read added files from the `ChangingFiles` object
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 23 Sep 2020 15:13:44 +0200] rev 45571
sidedata: add a `decode_files_sidedata` function
Right now the function mostly gather existing code to build a consistent object.
However having this function allow us prepare all user code independently from
the actual side data format change (and associated encoding/decoding changes)
Strictly speaking, we could not need to passe the sidedata explicitly since we
have access to it though the `changelogrevision` object. However, the short
term goal is to drop that first parameter to only pass the sidedata binaries.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Sep 2020 15:37:32 +0200] rev 45570
changelog: add a `changes` property on `changelogrevision`
For the sidedata storage we are moving toward "all in one" block containing the
equivalent of a "ChangingFiles" instance. We do various refactoring beforehand
to prepare the usage of theses new data in the code.
Since the object use slots, the "property cache" tricks cannot be used, and we
cache the value manually.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 22 Sep 2020 10:27:35 +0200] rev 45569
sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata`
We are storing more than copies information, so lets make it clear.
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:45:37 +0900] rev 45568
log: pass around --rev option by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:39:58 +0900] rev 45567
log: parse --limit option by logcmdutil.parseopts()
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:35:26 +0900] rev 45566
log: pass around --follow/--follow-first options by walkopts
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Sep 2020 21:06:16 +0900] rev 45565
log: introduce struct that carries log traversal options
I tried to refactor logcmdutil.getrevs() without using an options struct,
but none of these attempts didn't work out. Since every stage of getrevs()
needs various log command options (e.g. both matcher and revset query need
file patterns), it isn't possible to cleanly split getrevs() into a command
layer and a core logic.
So, this patch introduces a named struct to carry command options in slightly
abstracted way, which will be later used by "hg grep" and "hg churn". More
fields will be added to the walkopt struct.
Type hints aren't verified. I couldn't figure out how to teach pytype to
load its own attr type stubs in place of our .thirdparty.attr. Conditional
import didn't work. s/^from \.thirdparty // is the only way I found pytype
could parse the @attr.ib decorator.