Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 13 Jul 2019 23:45:32 -0400] rev 42620
convert: add a config option to help doing identity hg->hg conversion
I want to change the computation of the list of files modified by a
commit. In principle, this would simply change a cache. But since this
information is stored in commits rather than a cache, changing it
means changing commit hashes (going forward).
Some users rely on the convert extension from hg to hg not changing
hashes when nothing changes (usually). Allow these users to preserve
hashes despite changes to the changelog files computation by reusing
these files lists when the manifest is unchanged (since these files
list are derived from the manifest).
Differential Revision: https://phab.mercurial-scm.org/D6643
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:55:51 -0400] rev 42619
tests: show the files fields of changelogs for many merges
I don't think there's coverage for many of the subtle cases, and I
found it hard to understand what the code is doing by reading it. The
test takes 40s to run on a laptop, or 9s with --chg.
I have yet to find a description of what the files field is supposed
to be for merges. I thought it could be one of:
1. the files added/modified/removed relative to p1 (wouldn't seem
useful, but `hg diff -c -r mergerev` has this behavior)
2. the files with filelog nodes not in either parent (i.e., what is
needed to create a bundle out of a commit)
3. the files added/removed/modified files by merge itself [1]
It's clearly not 1, because file contents merges are symmetric. It's
clearly not 2 because removed files and exec bit changes are
listed. It's also not 3 but I think it's intended to be 3 and the
differences are bugs.
Assuming 3, the test shows that, for merges, the list of files both
overapproximates and underapproximates. All the cases involve file
changes not in the filelog but in the manifest (existence of file
at revision, exec bit and file vs symlink).
I didn't look at all underapproximations, but they looked minor. The
two overapproximations are problematic though because they both cause
potentially long lists of files when merging cleanly.
[1] even what it means for the merge commit itself to change a file is
not completely trivial. A file in the merge being the same as in one
of the parent is too lax as it would consider that merges change
nothing when they revert all the changes done on one side. The
criteria used in the test and in the next commit for "merge didn't
touch a file" is:
- the parents and the merge all have the same file
- or, one parent didn't touch the file and the other parent contains
the same file as the merge
Differential Revision: https://phab.mercurial-scm.org/D6612
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 19:18:16 +0100] rev 42618
phabricator: handle local:commits time being string or int
When setting local:commits arcanist has different behaviour depending on
whether the repo is git or hg. With hg it sets the time as a number, since it
calls PHP's strtotime on the value, but with git it sets it as a string.
Normally this wouldn't be an issue since phabread wouldn't be interacting with
Phabricator Revisions for git repos, but Mozilla has a secondary workflow for
git users that uses the git-cinnabar tool to interact with their hg repos. When
a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central
it makes use of Mozilla's fork of arcanist, which works with their local git
version of m-c, and thus sets the local:commit time as a string, and then
translates the commit hashes.
Currently when encountering such DREVS phabread dies with "TypeError: %d format:
a number is required, not str".
phabsend also used to set it as a string but wouldn't have encountered the
issue with its own DREVs since it would read hg:meta first.
Differential Revision: https://phab.mercurial-scm.org/D6650
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 18:38:38 +0100] rev 42617
phabricator: demonstrate broken phabread on string local:commit times
Differential Revision: https://phab.mercurial-scm.org/D6649
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 02 Jul 2019 18:02:12 +0530] rev 42616
unshelve: add interactive mode
Until now, there is no way to `unshelve` selected changes only from
the stored shelve as given in
issue6162. This patch makes `unshelve`
perform with certain changes only by adding an interactive mode.
Differential Revision: https://phab.mercurial-scm.org/D6596
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 07 Jul 2019 10:54:41 -0400] rev 42615
blackbox: disable extremely verbose logging (
issue6110)
This is maybe not the best way to go about fixing this, but anything
is better than the status quo.
Differential Revision: https://phab.mercurial-scm.org/D6611
Taapas Agrawal <taapas2897@gmail.com> [Wed, 17 Jul 2019 22:24:17 +0530] rev 42614
continue: added support for unshelve
This patch adds the support for `ushelve` in `hg continue` plan.
`hgcontinueunshelve()` has been created for independent calls.
In case an interrupted unshelve is resumed via hg continue the
shelvedstate needs to be loaded seperately. This has been
ensured by `_loadunshelvedstate()`
`hgcontinueunshelve()` is then registered as `continuefunc` for state
detection API.
Results are shown as tests.
Differential Revision: https://phab.mercurial-scm.org/D6652
Taapas Agrawal <taapas2897@gmail.com> [Tue, 16 Jul 2019 01:59:28 +0530] rev 42613
continue: added support for rebase
This adds support of rebase to hg continue plan.
An independent continue logic for rebase is created
under continuerebase() function. For this a seperate
rebaseruntime object is created under the function to
handle an interrupted rebasestate.
Results of tests are shown.
Differential Revision: https://phab.mercurial-scm.org/D6646
Taapas Agrawal <taapas2897@gmail.com> [Mon, 15 Jul 2019 22:23:31 +0530] rev 42612
continue: added logic for hg continue
This is part of GSoC19 project `Implement abort and
continue commands`. This patch is part of the continue plan.
This adds the basic logic for hg continue. This command
aborts an multistep operation like graft, histedit, rebase,
transplant and unshelve if they are in an unfinished state.
The first part of the logic is determining the unfinished
operation from the state detection API under statemod.
This API is extended to support hg continue by adding a method
to register the abort logic as a function (here continuefunc).
Once the unfinished operation is determined the registered
logic is used to resume the command in case it is interrupted.
The benefit of this kind of framework is that any new extension
developed can support hg continue by registering the command
and logic under statedetection API.
hg continue currently supports --dry-run/-n flag only.
It is used to dry run hg abort
Differential Revision: https://phab.mercurial-scm.org/D6645
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Jul 2019 18:15:51 +0200] rev 42611
rust-utils: remove buggy assertion
While this assertion had good intentions, it broke existing behavior with a
nasty panic.
Differential Revision: https://phab.mercurial-scm.org/D6651