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: suggest help -e histedit
Users unfamiliar with an extension should be reading the
documentation for the feature, not the 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.