Mon, 05 Oct 2015 12:37:26 -0400 templater: protect word() from crashing on out of range negative value stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 05 Oct 2015 12:37:26 -0400] rev 26502
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.
Fri, 02 Oct 2015 13:00:47 -0700 commands: add a new debug command to print merge state
Siddharth Agarwal <sid0@fb.com> [Fri, 02 Oct 2015 13:00:47 -0700] rev 26501
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.
Wed, 30 Sep 2015 21:22:31 -0700 merge.mergestate: factor out code to validate v1/v2 records
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:22:31 -0700] rev 26500
merge.mergestate: factor out code to validate v1/v2 records We're going to need this in another place in upcoming patches.
Tue, 06 Oct 2015 13:19:05 -0700 localrepo: prevent wlock from being inherited when a transaction is running
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:19:05 -0700] rev 26499
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.
Tue, 06 Oct 2015 13:13:31 -0700 lock: add a way to prevent locks from being inherited
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:13:31 -0700] rev 26498
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.)
Tue, 06 Oct 2015 15:55:50 -0700 test-fncache: use args/kwargs for lock wrapper
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 15:55:50 -0700] rev 26497
test-fncache: use args/kwargs for lock wrapper This is annoying to keep up to date, and also just plain unnecessary.
Tue, 06 Oct 2015 15:07:00 -0400 rebase: enable histedit for useful help with it
timeless@mozdev.org [Tue, 06 Oct 2015 15:07:00 -0400] rev 26496
rebase: enable histedit for useful help with it
Tue, 06 Oct 2015 15:01:25 -0400 rebase: suggest help -e histedit
timeless@mozdev.org [Tue, 06 Oct 2015 15:01:25 -0400] rev 26495
rebase: suggest help -e histedit Users unfamiliar with an extension should be reading the documentation for the feature, not the command.
Tue, 06 Oct 2015 15:05:40 -0400 rebase: factor out histedit help command
timeless@mozdev.org [Tue, 06 Oct 2015 15:05:40 -0400] rev 26494
rebase: factor out histedit help command
Sun, 04 Oct 2015 22:35:36 +0900 util: use tuple accessor to get accurate st_mtime value (issue4836)
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:35:36 +0900] rev 26493
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip