i18n: fix non-matching 1st line indentations When generating documentation, indentation must match for getting the same view for translated messages. Often an output is generated anyway, but it can look different. When a syntactically wrong indentation change is done, runrst will fail (this is detected by test-gendoc.t). Fix the simple places. When translation knowledge is necessary, the entry is marked as fuzzy (and therefore skipped when generating translations). A translator can fix it later.

i18n: fix some non matching quotation marks in translations A test for this is in preparation.

i18n: do not translate rst syntax .. note:: .. note:: is rst syntax which must not be translated. Fix this in the translations. This is not the first time this happens, so there should be a note for the translator. A later patch will change the generation of the po files to write this automatically. A test in i18n/check-translation.py could help as well.

i18n-pt_BR: synchronized with 268a5ab5c27b

subrepo: make it possible to update to hidden subrepo revisions When a subrepo revision was hidden it was considered missing and mercurial was unable to update to the corresponding parent revision. Instead warn the user of the problem and let it choose what to do (the default is to udpate anyway).

subrepo: remove unnecessary else clause in hgsubrepo._get This revision has no behaviour change. It simply removes an unnecessary else that follows an if / return block. The change looks big because a big chunk of code has been unindented one level.

subrepo: do not try to get hidden revisions If a subrepo revision is hidden (because it was amended, for example) it does not make sense to try to "get" it from the remote subrepository. Note that in order to avoid making the change look bigger than it is, this adds an unnecessary else clause. This will be removed on a follow up patch.

parsers: fix 'unsigned expression is always true' warning (issue4142) On Mac OS gcc-llvm throws an -Wtautological-compare warning because flen is defined as an unsigned integer, therefore flen < 0 is always true.

wix: pull in new templates

phase: properly compute ancestors of --rev on push (issue3786) Now that discovery is working on unfiltered changeset, I had a good occasion to look at that bug again. This let me realise that a trivial node vs rev comparision was the cause of this two years old bugs… Happy second birthday phases!

hgext: fix one typo in rebase

templater: selecting a style with no templates does not crash (issue4140) Running `hg log --style compact` (or any other style) raised a traceback when no template directory was there. Now there is a message: Abort: style 'compact' not found (available styles: no templates found, try `hg debuginstall` for more info) There is no test because this would require to rename the template directory. But this would influence other tests running in parallel. And when the test would be aborted the wrong named directory would remain, especially a problem when running with -l.

makefile: add $ to environment variables in help message

Added signature for changeset 8862469e16f9

Added tag 2.9-rc for changeset 8862469e16f9

merge with i18n

i18n: fix trailing '::' on translated messages Reported by FUJIWARA Katsunori <foozy@lares.dti.ne.jp>.

merge default into stable for 2.9 code freeze

tests: stop tracking tests/gpg/random_seed test-gpg.t left the random_seed file as modified. That was slightly confusing ... and it was accidentally changed in ea4996754d91. The seed is created on demand and there is no reason to track it. There is also no reason to leak state between test runs so we let the test clean up after running.

tests: 'hghave tic' also requires curses support in Python test-status-color.t would fail when using a Python without curses.

test-import-merge: mangle file in binary mode This should fix a test breakage on Windows.

localrepo: drop dead comment

record: re-enable whitespace-ignoring options It looks like somewhere down the line, patch.diffopts changed the names of the options that it recognises, but record.recordfunc wasn't updated to the new names. Instead of trying to write down names at all, we now use whatever names are provided in commands.diffwsopts and pass that along to patch.diffopts, along with a couple of custom options

record: use commands.diffwsopts instead of ad-hoc diffopts The record extension is writing its own version of commands.diffwsopts which is identical to commands.diffwsopts. Based on the principle that code duplication increases maintenance burden, this patch removes record's ad-hoc diffopts in favour of commands.diffwsopts

phases: add a formal note that hash of secret changeset may leak out For technical reason (discovery, obsolescence marker) the hash of secret changeset are communicated outside of your repo. We clarifie that in the help so that people does not used hash of secret changeset as nuclear launch code.

largefiles: stylistic cleanup of filemerge

largefiles: show hashes before prompting for conflict resolution The largefile hashes are mostly an implementation detail, but they are "leaked" in several places anyway, and showing the hashes is better than not giving the user any information about the options in the prompt. The hashes are long, but it is largefile hashes and it would thus be confusing to shorten them.

largefiles: don't try to explain rename history before prompt for conflicts Before it tried to explain the exact situation when merging moved largefiles. That do not happen for normal merges and is not more relevant for largefiles than for normal files. It is unneeded complexity - remove it.

largefiles: drop redundant special handling of merges of renames It is unclear what cases this was supposed to cover but it do no longer seem relevant.

diff: search beyond ancestor when detecting renames This removes an optimization that was introduced in 91eb4512edd0 but was too aggressive - as indicated by how it changed test-mq-merge.t . We are walking filelogs to find copy sources and we can thus not be sure to hit the base revision and find the renamed file there - it could also be in the first ancestor of the base ... in the filelog. We are walking the filelog and can thus not easily know when we hit the first ancestor of the base revision and which filename to look for there. Instead, we use _findlimit like mergecopies do: The lower bound for how far we have to go is found from the lowest changelog revision that is an ancestor of only one of the compared revisions. Any filelog ancestor with a revision number lower than that revision will be the ancestor of both compared revisions, and there is thus no reason to go further back than that.