This allows us to provide alternate search keys for 64bit operating systems that
may have 32bit merge tools installed. Presumably it may find other uses.
The default behaviour is to commit subrepositories with uncommitted changes. In
my experience this is usually undesirable:
- Changes to dependencies are often debugging leftovers
- Real changes should generally be applied on the source project directly,
tested then committed. This is not always possible, subversion subrepos may
include only a small part of the source project, without the tests.
Setting ui.commitsubrepos=no will now abort commits containing such modified
subrepositories like:
$ hg --config ui.commitsubrepos=no ci -m msg
abort: uncommitted changes in subrepo sub
I ruled out the hook solution because it does not easily take --include/exclude
options in account. Also, my main concern is whether this flag could cause
problems with extensions. If there are legitimate reasons for callers to
override this behaviour (I could not find any), they might either override at ui
level, or we could add an argument to localrepo.commit() later.
v2:
- Renamed ui.commitsubs to ui.commitsubrepos
- Mention the configuration entry in hg help subrepos
If --insecure specified, it behaves in the same way as no web.cacerts
configured.
Also shows hint for --insecure option when _verifycert() failed. But currently
the hint isn't displayed on SSLError, because it needs a certain level of
changes.
Known fingerprints of HTTPS servers can now be configured in the
hostfingerprints section. That makes it possible to verify the identify of web
servers without configuring and trusting the CA chain.
Limitations:
* Portnumbers are ignored, just like with ordinary certificates.
* Host name matching is case sensitive.
Currently we only support enabling TLS by using SMTP STARTTLS extension. But
not all the servers support it.
With this patch, user can choose which way to enable TLS:
* Default:
tls = none
port = 25
* To use STARTTLS:
tls = starttls
port = 465
* To use SMTP over SSL:
tls = smtps
port = 465
To keep backward compatibility, when tls = true, we use STARTTLS to enable TLS.
Signed-off-by: Zhigang Wang <w1z2g3@gmail.com>
It is an intermediate file used to produce the hg.1 and .hg.1.html
files and is not useful for people who download the tarball. It will
be regenerated automatically by the Makefile if users want to rebuild
the documentation.
This was an old left-over from when the synopsis line was used as a
header. We now have the command name by itself as the header and the
synopsis as a literal block immediately after..
Adds a section in the hg.1 manpage and corresponding hg.1.html
file. Each extension is listed with its module docstring, followed by
the commands defined by that extendsion.
Creates help for extensions by extracting doc strings from the extension modules
and its commands.
When getting docstrings from the source they are indented to look good
in the code. This indentation interferes with how the text is parsed
by rst. Therefore this indentation is removed.
I have made a help topic for merge tools. The text in the topic is
based on the http://mercurial.selenic.com/wiki/MergeProgram page from
the wiki, along with some extra information on the internal merge tools.
Mads Kiilerich pointed out that 1e4ade283b02 was too eager since the
prefix and password keys may contain $-signs. So this only add the
username to the list of keys that are expanded.
This also updates the documentation to match.
python hooks are passed two new keyword arguments:
- opts: a dict of options; unsepcified options are set to their default
- pats: a list of arguments
shell hooks receive two new variables containing string representations
of the above data:
- $HG_OPTS
- $HG_PATS
for example, the opts and pats for 'hg -f v1.1' would be:
{'force': True, 'message': '', 'rev': '', 'user': '', 'date': '', 'local': None, 'remove': None, 'mq': None}
['v1.1']
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.