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.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
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.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
This helps to factor out scmutil.revrange() calls from _getpatches() and
_getoutgoing(). In future patches, a smartset will be passed to _getpatches().
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
This change touches every module in which repository.opener was being used, and
changes it for the equivalent repository.vfs. This is meant to make it easier
to split the repository.vfs into several separate vfs.
It should now be possible to remove localrepo.opener.
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 current output is mostly a wall of text. This makes it hard to
actually check something for people with lazy eyes. We use labels and
colors to make it more joyful (and get the patch summaries to stand
out). The colors have been arbitrarily choosen. They can be changed
later if someone has a more scientific choice.
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.
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.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Before this patch, the certificate of the SMTP server for STARTTLS or
SMTPS isn't verified.
This may cause man-in-the-middle security problem (stealing
authentication information), even though SMTP channel itself is
encrypted by SSL.
When "[smtp] tls" is configured as "smtps" or "starttls", this patch:
- uses classes introduced by preceding patches instead of "SMTP" or
"SMTP_SSL" of smtplib, and
- verifies the certificate of the SMTP server, if "[smtp]
verifycert" is configured as other than False
"[smtp] verifycert" can be configured in 3 levels:
- "strict":
This verifies peer certificate, and aborts if:
- peer certification is not valid, or
- no configuration in "[hostfingerprints]" and "[web] cacerts"
This is default value of "[smtp] verifycert" for security.
- "loose":
This verifies peer certificate, and aborts if peer certification is
not valid.
This just shows warning message ("certificate not verified"), if
there is no configuration in "[hostfingerprints]" and "[web]
cacerts".
This is as same as verification for HTTPS connection.
- False(no verification):
Peer certificate is not verified.
This is as same as the behavior before this patch series.
"hg email --insecure" uses "loose" level, and ignores "[web] cacerts"
as same as push/pull/etc... with --insecure.
Ignoring "[web] cacerts" configuration for "hg email --insecure" is
already done in "dispatch._dispatch()" by looking "insecure" up in the
table of command options.
The help text shows "-c/--confirm", which implies that -c is an alias
for --confirm. Actually, it is an alias for --cc. Correct the text
by removing -c.
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
...
Another version could have returned a revset expression from
getoutgoing(), but we do not know how many times it will be resolved, so
better do it once explicitely.
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.
This matches our pre-existing behavior from:
changeset: 12197:0a3b85866451
user: Christian Ebert <blacktrash@gmx.net>
files: hgext/patchbomb.py tests/test-patchbomb.t
description:
patchbomb: show prompt and selection in non-interactive mode
changeset: 8940:023d1310d8a4
user: Mads Kiilerich <mads@kiilerich.com>
date: Sun Jun 21 03:13:38 2009 +0200
files: mercurial/ui.py tests/test-merge-prompt.out tests/test-merge-tools.out
description:
ui.prompt: Show prompt and selection in non-interactive mode
