Sun, 04 Oct 2015 22:25:29 +0900 util: extract stub function to get mtime with second accuracy
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:25:29 +0900] rev 26492
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.
Mon, 05 Oct 2015 14:37:59 -0700 scmutil: add a way for a repo's wlock to be inherited by a subprocess
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:37:59 -0700] rev 26491
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.
Mon, 05 Oct 2015 14:34:52 -0700 scmutil: add a way for a subprocess to be run with an inheritable lock
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:34:52 -0700] rev 26490
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.
Mon, 05 Oct 2015 14:27:37 -0700 localrepo: add a way to get the current wlock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:27:37 -0700] rev 26489
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.
Mon, 05 Oct 2015 14:26:53 -0700 localrepo: add a way to get the current lock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:26:53 -0700] rev 26488
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.
Thu, 24 Sep 2015 13:58:18 -0400 test-help: verify that extension keywords appear in help templates
timeless@mozdev.org [Thu, 24 Sep 2015 13:58:18 -0400] rev 26487
test-help: verify that extension keywords appear in help templates fixed by a2291c9c85a1
Mon, 24 Aug 2015 23:30:17 -0400 templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:30:17 -0400] rev 26486
templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Sun, 23 Aug 2015 23:44:58 -0400 templater: introduce {latesttag()} function to match a pattern (issue4184)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Aug 2015 23:44:58 -0400] rev 26485
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.
Mon, 24 Aug 2015 23:07:00 -0400 templatekw: introduce showlatesttags() to handle {latesttag} keywords
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:07:00 -0400] rev 26484
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.
Mon, 05 Oct 2015 21:11:50 -0400 templatekw: factor out the changessincetag calculation to a private method
Matt Harbison <matt_harbison@yahoo.com> [Mon, 05 Oct 2015 21:11:50 -0400] rev 26483
templatekw: factor out the changessincetag calculation to a private method This will be reused in the next patch.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip