This can be used to flag patches by branch or topic automatically. Flags
optionally given by --flag option are exported as {flags} template keyword,
so you can add --flag V2.
Revlog can now be configured to store full snapshot only. This is used on the
changelog. However, the changegroup packing was still recomputing deltas to be
sent over the wire.
We now just reuse the full snapshot directly in this case, skipping delta
computation. This provides use with a large speed up(-30%):
# perfchangegroupchangelog on mercurial
! wall 2.010326 comb 2.020000 user 2.000000 sys 0.020000 (best of 5)
! wall 1.382039 comb 1.380000 user 1.370000 sys 0.010000 (best of 8)
# perfchangegroupchangelog on pypy
! wall 5.792589 comb 5.780000 user 5.780000 sys 0.000000 (best of 3)
! wall 3.911158 comb 3.920000 user 3.900000 sys 0.020000 (best of 3)
# perfchangegroupchangelog on mozilla central
! wall 20.683727 comb 20.680000 user 20.630000 sys 0.050000 (best of 3)
! wall 14.190204 comb 14.190000 user 14.150000 sys 0.040000 (best of 3)
Many tests have to be updated because of the change in bundle content. All
theses update have been verified. Because diffing changelog was not very
valuable, the resulting bundle have similar size (often a bit smaller):
# full bundle of mozilla central
with delta: 1142740533B
without delta: 1142173300B
So this is a win all over the board.
The bundle2 changegroup part has an advisory param saying how many
changesets are in the part. Before this patch, we were setting
this part when generating bundle2 parts via the wire protocol but
not when generating local bundle2 files.
A side effect of not setting the changeset count part is that progress
bars don't work when applying changesets. As the tests show, this
impacted clone bundles, shelve, backup bundles, `hg unbundle`, and
anything touching bundle2 files.
This patch adds a backdoor to allow us to pass state from
changegroup generation into the unbundler. We store the number
of changesets in the changegroup in this state and use it to
populate the aforementioned advisory part parameter when generating
the bundle2 bundle.
I concede that I'm not thrilled by how state is being passed in
changegroup.py (it feels a bit hacky). I would love to overhaul the
rather confusing set of functions in changegroup.py with something that
passes rich objects around instead of e.g. low-level generators.
However, given the code freeze for 3.9 is imminent, I'd rather not
undertake this endeavor right now. This feels like the easiest way
to get the parameter added to the changegroup part.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
This changeset is taken on stable for consistency with similar update done
before the freeze.
See dc90bb772edc, 675a0be03493, 518b94d8f911 and 149a699cfd98.
With -n/--test and if the PAGER environment variable is set, 'hg email' send its
output to the user defined pager.
If the pager capture the output, the test is unable verify it.
Unsetting the PAGER environment variable force 'hg email' to write to stdout.
Previously it wasn't possible to use configuration to avoid
being prompted for e.g. a CC list when using patchbomb to send
emails.
We now make it possible to supply an empty value.
Generaldelta changes some of the default targets for 'hg bundle'. All cases are
already properly tested but some ambiguous specifications are affected.
Advertising that the patch are available to be pulled requires that to be true.
So we check revision availability on the remote before sending any email.
patchbomb relies on the 'hg bundle' command to generate an attached bundle using
--bundle. However, while 'hg bundle' has a --type option, patchbomb did not.
This is becoming very relevant since we are about to issue bundle2 for
general-delta repository.
This was tracked as issue4863
This config allows to specify a public location where your changeset can be
found. It then include a dedicated patch header show a command to be used to
retrieve the change. See the test for example.
This is flagged as experimental because this feature is not safe until we have
more logic to test that:
- changeset actually exists on destination
- changeset is draft on destination.
As all this is experimental, bike shedding can happily happens before we remove
the experimental flag.
We were wrapping the ui class again and again (uisetup, reposetup,
subrepo setup, remote repo setup, etc). We now avoid that. This has
impact on tests that were double-printing data because of this.
When set to true, this option will make patchbomb always ask for confirmation
before sending the email. Confirmation is a powerful way to prevent stupid
mistakes when the sending patches.
This should let me get rid of my global alias adding
--confirm to hg email.
I know that some people may get bitten when moving from a machine with confirm
configured to a machine where it is not, but I think it is worth the risk.
This option allows the user to control the default behavior for
including an introduction message. This avoids having to tirelessly
skip the intro for people contributing to Mercurial.
The three possibles values are:
- always,
- auto (default, current behavior),
- never.
I was thinking of ("true", "false", "") (empty value being auto) but I ruled it
out as too confusing.
This new config option reuses the pre-existing 'patchbomb' section.
The whitespace diffopts break lossless transmission, and the format-changing
ones make import harder. We expect parsers to be able to read git-style diffs,
though.
The tests often set ui.interactive to control normally interactive prompts from
stdin. That gave an output where it was non-obvious what prompts got which
which response, and the output lacked the newline users would see after input.
Instead, if the input not is a tty, write the selection and a newline.
Python 2.7.7 and later (as well as some ubuntu/debian packages of
2.7.6) include a fix that makes the email module more pedantically
correct for MIME boundaries, but this breaks our tests. We work around
this by filtering the output of any 'hg email' invocations in the test
that produce MIME messages.
This currently has the side effect that the 0 of N message has no
series-id. This won't matter for Mercurial's own use, but may be
undesirable for other projects depending on their workflow.
The way the header is inserted is intentionally a little funny to make
the test expectation diff easier to review.
This makes it significantly less painful to use --interactive on
run-tests, as you can now use the recorded regular expression
substitutions to fix up the glob lines and produce zero diffs.
This also tightens the expectations of a few of the lines for the MIME
boundaries - it just seemed like the thing to do while in here and
causing some changes.
Now that we have patch index and series size information, having a unique series
identifier will helps tool to glue all email back together without any
additional logic.
We includes information about the series being patch bombed in all email. Two
new headers are added:
* X-Mercurial-Series-Index: index of the patches in the series (starts at 1)
* X-Mercurial-Series-Total: The total number of patches in the series
This information is available in the email subject line, but having them
formalized in the header will helps automated tools to process patches send with
modern mercurial.
'export' is the official export format and used by patchbomb, but it would only
show date as a timestamp that most humans might find it hard to relate to. It
would be very convenient when reviewing a patch to be able to see what
timestamp the patch will end up with.
Mercurial has always used util.parsedate for parsing these headers. It can
handle 'all' date formats, so we could just as well use a readable one.
'export' will now use the format used by 'log' - which is the format described
as 'Unix date format' in the templating help. We assume that all parsers of '#
HG changeset patch'es can handle that.
Before this change, the thread hierarchy looked like this:
PARENT
PATCH1/x
PATCH2/x
PATCH3/x
...
Now it is:
PARENT
PATCH1/x
PATCH2/x
PATCH3/x
...
With an introductory message the behaviour is unchanged:
PARENT
INTRO
PATCH1/x
PATCH2/x
PATCH3/x
...
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
There is currently no way to make patchbomb include patches both as attachments
and as inline text. This would be quite convenient when sending patches to
people who use web email clients (e.g. gmail) which often mangle the patches,
making them hard to apply.
The default behavior of the email command is unchanged. However it is now
possible to use the --body flag _in addition_ to the -i or -a flags, in which
case the patchbomb emails will contain the patch as inline body text and as an
attachment.
A new test has been added to test-patchbomb.t ("test attach for single
patch"), based on the existing test called "test attach for single patch" test.
