filemerge: indent filemerge.filemerge This will make upcoming patches much easier to review.

test-bundle-type: replace unbundle with debugbundle We now have a convenient command to look at bundle contents, let's use it.

bundle: extract the parsing of the bundle type in a function We are going to introduce significant extensions of the bundle parsing code to support creation of bundle2 through the bundle command. As an early step, we extract the logic in its own function.

changegroup: add version argument to getchangegroup For some obscure reasons (probably upsetting a Greek goddess), getchangegroup did not had a 'version' argument to control the changegroup version. We fixes this to allow cg02 to be used with 'hg bundle' in the future.

changegroup: add version argument to getlocalchangegroup For some obscure reasons (probably upsetting a Greek goddess), getlocalchangegroup did not have a 'version' argument to control the changegroup version. We fix this to allow cg02 to be used with 'hg bundle' in the future.

shelve: bundle using bundle2 if repository is general delta (issue4862) This will prevent expensive delta computation on bundling and is similar to what we do for strip backup.

shelve: move changegroup generation inside writebundle We will generate different changegroup if general delta is enabled so we gather this in the lower level function. There wasn't any good reason to have it in the main code anyway.

shelve: compress on-disk bundle Shelve is using 'HG10UN' bundle for no obvious reason. Changing this to 'HG10BZ' as we do for other bundle stored on disk.

merge with stable

notify: fix fromauthor setting for 'incoming' hook type (issue4194) Set the author field in notification emails for the 'incoming' hook type in addition to 'changegroup' and 'outgoing' types.

templater: protect word() from crashing on out of range negative value The function isn't documented to work with negative values at all, but it does, which can be useful. However, the range check didn't account for this.

commands: add a new debug command to print merge state We're going to be extending the merge state very soon, and this will give us a way to test all that.

merge.mergestate: factor out code to validate v1/v2 records We're going to need this in another place in upcoming patches.

localrepo: prevent wlock from being inherited when a transaction is running Review feedback from Pierre-Yves David. A separate line of work is working to ensure that dirstate writes are written to a separate 'pending' file while a transaction is active. Lock inheritance currently conflicts with that, so dodge the issue by simply preventing inheritance while a transaction is running. Custom merge drivers aren't going to run inside a transaction, so this doesn't affect that.

lock: add a way to prevent locks from being inherited We want to prevent locks from being inherited sometimes (e.g. when there's a currently running transaction, which will break a lot of assumptions we're making in here.)

test-fncache: use args/kwargs for lock wrapper This is annoying to keep up to date, and also just plain unnecessary.

rebase: enable histedit for useful help with it

rebase: suggest help -e histedit Users unfamiliar with an extension should be reading the documentation for the feature, not the command.

rebase: factor out histedit help command

util: use tuple accessor to get accurate st_mtime value (issue4836) Because st.st_mtime is computed as 'sec + 1e-9 * nsec' and double is too narrow to represent nanoseconds, int(st.st_mtime) can be 'sec + 1'. Therefore, that value could be different from the one got by osutils.listdir(). This patch fixes the problem by accessing to raw st_mtime by tuple index. It catches TypeError to fall back to st.st_mtime because our osutil.stat does not support tuple index. In dirstate.normal(), 'st' is always a Python stat, but in dirstate.status(), it can be either a Python stat or an osutil.stat. Thanks to vgatien-baron@janestreet.com for finding the root cause of this subtle problem.

util: extract stub function to get mtime with second accuracy This function is trivial but will need a long comment why it can't use st.st_mtime. See the next patch for details.

scmutil: add a way for a repo's wlock to be inherited by a subprocess This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In the future, we'll call this for custom merge drivers.

scmutil: add a way for a subprocess to be run with an inheritable lock This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In an upcoming patch, we'll add an API for the wlock to be inherited.

localrepo: add a way to get the current wlock if it's held This will be useful to pass around a reference to the lock to some functions we're going to add to scmutil. We don't want those functions to live in localrepo to avoid bloat.

localrepo: add a way to get the current lock if it's held We'll use this in upcoming patches to return a reference to the wlock if it's held.

test-help: verify that extension keywords appear in help templates fixed by a2291c9c85a1

templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword

templater: introduce {latesttag()} function to match a pattern (issue4184) This allows the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It doesn't appear that the existing keyword can be given an optional argument. There is a keyword, function and filter for 'date', so it doesn't seem harmful to introduce a new function with the same name as an existing keyword. Most functions are pretty Mercurial agnostic, but there is {revset()} as precedent. Even though templatekw.getlatesttags() returns a single tuple, one entry of which is a list, it is simplest to present this as a list of tags instead of a single item, with each tag having a distance and change count attribute. It is also closer to how {latesttag} returns a list of tags, and how this function works when not given a '%' operator.

templatekw: introduce showlatesttags() to handle {latesttag} keywords The keywords {changes}, {distance} and {tag} will be available on a future template method that will allow pattern matching against tag names. For consistency, these should be available on the existing {latesttag} keyword as well. I debated whether or not to add {tag} instead of just continuing with the existing {latesttag}. But it seems clearer not to have the same name for two distinct things (a list in the LHS of %, and an individual tag value on the right). The value of latesttags[0] is the date of commit for the cset to which the tag is applied (i.e. not the date the tag was applied), and therefore isn't made visible because it doesn't seem interesting. It appears that this is merely an internal implementation detail for sorting csets in a stable manner when there are different branches.

templatekw: factor out the changessincetag calculation to a private method This will be reused in the next patch.