Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:31:23 +0530] rev 45582
configitems: add a new config option to control new filenode functionality
This series is adding functionality where we can force create a new filenode for
some files on a merge-commit. This is meant to represent an explicit choice made
by user and hence distingusing the file in the merged commit with the file in
parent by creating a new filenode instead of using the parent one.
This introduces a experimental config option under which this functionality
will be hidden.
A new testcase is added in tests/test-merge-criss-cross.t to test the new
functionality while making the option does not break other scenarios.
Differential Revision: https://phab.mercurial-scm.org/D9026
Connor Sheehan <sheehan@mozilla.com> [Wed, 23 Sep 2020 14:20:49 -0400] rev 45581
git: add test showing `hg commit -i` working on a git repo
Shows `hg commit -i` working on a git repo via the `git`
extension. Adds working directory changes to files `alpha` and
`beta`, then selects only `alpha` changes and commits them.
As of now this would fail for a filename that
includes uppercase characters due to the lack of case folding
support in the extension.
Differential Revision: https://phab.mercurial-scm.org/D9081
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 11:53:44 -0700] rev 45580
merge: replace calls to hg.updaterepo() by merge.update()
The former no longer buys us anything.
Differential Revision: https://phab.mercurial-scm.org/D9067
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 09:57:29 -0700] rev 45579
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 45578
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 45577
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 45576
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 45575
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 45574
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 45573
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.