test-rebase: exhibit revisions which should have been skipped
This will be fixed in the next commit.
v2:
- Display emptied grafted revisions
- Use --git flag
transplant: do not rollback on patching error (
issue3379)
Otherwise, all transplanted revisions are gone and the failing one cannot be
fixed (unless it is the first one).
I do not know what is the expected behaviour with rollback, probably something
pull-like. Non-conflicting cases should work as previously. But something like:
$ hg transplant r1 r2
commiting r1 as c1
failing r2
$ hg transplant --continue
committing r2 as c2
$ hg rollback
would reset the repository to its state before the "transplant --continue"
instead of the whole transplant session. To fix this we might need a way to
open an existing journal file, not sure this is worth the pain.
patch: fix patch hunk/metdata synchronization (
issue3384)
Git patches are parsed in two phases: 1) extract metadata, 2) parse actual
deltas and merge them with the previous metadata. We do this to avoid
dependency issues like "modify a; copy a to b", where "b" must be copied from
the unmodified "a".
Issue3384 is caused by flaky code I wrote to synchronize the patch metadata
with the emitted hunk:
if (gitpatches and
(gitpatches[-1][0] == afile or gitpatches[-1][1] == bfile)):
gp = gitpatches.pop()[2]
With a patch like:
diff --git a/a b/c
copy from a
copy to c
--- a/a
+++ b/c
@@ -1,1 +1,2 @@
a
+a
@@ -2,1 +2,2 @@
a
+a
diff --git a/a b/a
--- a/a
+++ b/a
@@ -1,1 +1,2 @@
a
+b
the first hunk of the first block is matched with the metadata for the block
"diff --git a/a b/c", then the second hunk of the first block is matched with
the metadata of the second block "diff --git a/a b/a", because of the "or" in
the code paste above. Turning the "or" into an "and" is not enough as we have
to deal with /dev/null cases for each file.
We I remove this broken piece of code:
# copy/rename + modify should modify target, not source
if gp.op in ('COPY', 'DELETE', 'RENAME', 'ADD') or gp.mode:
afile = bfile
because "afile = bfile" set "afile" to stuff like "b/file" instead of "a/file",
and because this only happens for git patches, which afile/bfile are ignored
anyway by applydiff().
v2:
- Avoid a traceback on git metadata desynchronization
commit: use ui.configbool when checking 'commitsubrepos' setting on --amend
Before this fix, having
[ui]
commitsubrepos = False
in the config file lead to
$ hg ci --amend -mx
abort: cannot amend recursively
doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns"
each help topics describe that patterns are "not rooted" and "rooted"
in themselves, but not describe about each other.
so, this may causes misunderstanding about "rooted"-ness of patterns.
doc: add description about re-opening closed heads to 'Head, closed branch' in glossary
doc: fix careless document miss for term 'Close changeset' in glossary
there is no term 'Changeset, close' in glossary.
'Close changeset' seems to have to be linked not to 'Branch, closed',
but to 'Head, closed branch', because only the latter explains about
"the changeset that marks a head as no longer interesting".
doc: fix careless document miss in help of hgext/notify
according to configuration example below, and direction of changeset
transference, this paragraph should describe about "changegroup" hook.
[hooks]
# one email for each incoming changeset
incoming.notify = python:hgext.notify.hook
# one email for all incoming changesets
changegroup.notify = python:hgext.notify.hook
# one email for all outgoing changesets
outgoing.notify = python:hgext.notify.hook
doc: fix explanation comment in acl extension
according to configuration in "acl.deny" below, group "@hg-denied"
also be denied for all files, so add such description to comment for
configuration.
[acl.deny]
# user6 will not have write access to any file:
** = user6
# Group "hg-denied" will not have write access to any file:
** = @hg-denied