subrepo: backout 519ac79d680b Unfortunately git 1.6 does not support the upstream parameter in for-each-ref.

url: fix check-code whitespace complaint

templater: use the parser.py parser to extend the templater syntax

templater: give slightly nicer error for unknown map entries

mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.

backout f08df4d38442

subrepo: backout f02d7a562a21 backing out f02d7a562a21 because it introduced a bug in .hgsubstate handling.

merge with i18n

merge with stable

fncachestore: copy dh directory before the manifest Before this patch, the copy order on clone was: requires 00changelog.i store\data store\00manifest.d store\00manifest.i store\00changelog.d store\00changelog.i store\dh store\fncache Which provides a theoretical non-zero probability of a race during clone where a very early reader might see a repository with missing revlog files if it sees 00changelog.i before all files inside dh have been copied. The dh directory is similar to the data directory -- just for files with long names (which are hashed). The manifest refers to files in data *and* dh, so dh should be copied before the manifest. This patch improves the copy order to: requires 00changelog.i store\data store\dh store\fncache store\00manifest.d store\00manifest.i store\00changelog.d store\00changelog.i I'm putting fncache to before the manifest while I'm at it, since fncache provides a mechanism to enumerate all repository files without visiting the manifest revisions. fncache depends only on data and dh. Note that data must be copied first, since copying data triggers the creation of the repository write lock in the destination repo (see hg.clone).

merge with i18n

i18n: merge with stable

i18n-da: synchronize with 5dac0d04b838

i18n-de: translated strings for the purge extension

merge with stable

https: warn when server certificate isn't verified Mercurial will verify HTTPS server certificates if web.cacerts is configured, but it will by default silently not verify any certificates. We now warn the user that when the certificate isn't verified she won't get the security she might expect from https: warning: localhost certificate not verified (check web.cacerts config setting) Self-signed certificates can be accepted silently by configuring web.cacerts to point to a suitable certificate file.

merge: document some internal return values.

check-code: catch os.path.relpath

check-code: catch "except as"

tests: eliminate fast-forward merge in test-tag

merge: fast-forward merge with descendant issue2538 gives a case where a changeset is merged with its child (which is on another branch), and to my surprise the result is a real merge with two parents, not just a "fast forward" "merge" with only the child as parent. That is essentially the same as issue619. Is the existing behaviour as intended and correct? Or is the following fix correct? Some extra "created new head" pops up with this fix, but it seems to me like they could be considered correct. The old branch head has been superseeded by changes on the other branch, and when the changes on the other branch is merged back to the branch it will introduce a new head not directly related to the previous branch head. (I guess the intention with existing behaviour could be to ensure that the changesets on the branch are directly connected and that no new heads pops up on merges.)

record: teach parsepatch() about non-git style headers These changes are not useful to record itself, since it is hard coded to always generate git style diffs. But it makes parsepatch() more generally useful for parsing normal patch files.

template: add showbranch template for {branch} Like showbranches, but always yields exactly one branch. Replaces the less correct {branches|nonempty}.

subrepo: avoids empty commit when .hgsubstate is dirty (issue2403) This patch avoids empty commit when .hgsubstate is dirty. Empty commit was caused by .hgsubstate being updated back to the state of the working copy parent when committing, if a user had changed it manually and not made any changes in subrepositories. The subrepository state from the working copies parent is compared with the state calculated as a result of trying to commit the subrepositories. If the two states are the same, then return None otherwise the commit is just done. The line: "committing subrepository x" will be written if there is nothing committed, but .hgsubstate is dirty for x subrepository.