Thu, 03 Mar 2016 14:29:19 +0000 fsmonitor: new experimental extension
Martijn Pieters <mjpieters@fb.com> [Thu, 03 Mar 2016 14:29:19 +0000] rev 28433
fsmonitor: new experimental extension Extension to plug into a Watchman daemon, speeding up hg status calls by relying on OS events to tell us what files have changed. Originally developed at https://bitbucket.org/facebook/hgwatchman
Wed, 02 Mar 2016 16:25:12 +0000 fsmonitor: dependencies for new experimental extension
Martijn Pieters <mjpieters@fb.com> [Wed, 02 Mar 2016 16:25:12 +0000] rev 28432
fsmonitor: dependencies for new experimental extension In preparation for the filesystem monitor extension, include the pywatchman library. The fbmonitor extension relies on this library to communicate with the Watchman service. The library is BSD licensed and is taken from https://github.com/facebook/watchman/tree/master/python. This package has not been updated to mercurial code standards.
Tue, 12 Jan 2016 04:45:29 +0000 setup: show how to set the module policy for imports
timeless <timeless@mozdev.org> [Tue, 12 Jan 2016 04:45:29 +0000] rev 28431
setup: show how to set the module policy for imports This is not technically needed, since mercurial.__version__ does not exist as a native module, but, without this style wrappings, if something else had a native flavor, the module loader would get upset. In principle, the `env` object is trying to set HGMODULEPOLICY for children, so, conceptually we should set it for this in-process child.
Wed, 09 Mar 2016 15:47:01 +0000 setup: create a module for the modulepolicy
timeless <timeless@mozdev.org> [Wed, 09 Mar 2016 15:47:01 +0000] rev 28430
setup: create a module for the modulepolicy Instead of rewriting __init__ to define the modulepolicy, write out a __modulepolicy__.py file like __version__.py This should work for both system-wide installation and in-place build. Therefore we can avoid relying on two separate modulepolicy rules, '@MODULELOADPOLICY@' and 'mercurial/modulepolicy'.
Wed, 09 Mar 2016 08:08:27 -0800 rebase: turn rebaseskipobsolete on by default
Kostia Balytskyi <ikostia@fb.com> [Wed, 09 Mar 2016 08:08:27 -0800] rev 28429
rebase: turn rebaseskipobsolete on by default Consider the following use case. User has a set of commits he wants to rebase onto some destination. Some of the commits in the set are already rebased and their new versions are now among the ancestors of destination. Traditional rebase behavior would make the rebase and effectively try to apply older versions of these commits on top of newer versions, like this: a` --> b --> a` (where both 'a`' and 'a``' are rebased versions of 'a') This is not desired since 'b' might have made changes to 'a`' which can now result in merge conflicts. We can avoid these merge conflicts since we know that 'a``' is an older version of 'a`', so we don't even need to put it on top of 'b'. Rebaseskipobsolete allows us to do exactly that. Another undesired effect of a pure rebase is that now 'a`' and 'a``' are both successors to 'a' which is a divergence. We don't want that and not rebasing 'a' the second time allows to avoid it. This was not enabled by default initially because we wanted to have some more experience with it. After months of painless usages in multiple places, we are confident enough to turn it on my default.
Wed, 09 Mar 2016 23:57:15 +0900 graphlog: bring back color to node symbol template
Yuya Nishihara <yuya@tcha.org> [Wed, 09 Mar 2016 23:57:15 +0900] rev 28428
graphlog: bring back color to node symbol template Follows up 3356bf61fa25. A ui object is required to render labels.
Tue, 16 Feb 2016 21:44:13 +0900 revset: add inspection data to max() and min() functions
Yuya Nishihara <yuya@tcha.org> [Tue, 16 Feb 2016 21:44:13 +0900] rev 28427
revset: add inspection data to max() and min() functions We are likely to be interested in how these functions build a result set.
Tue, 16 Feb 2016 21:43:51 +0900 revset: add inspection data to limit() and last() functions
Yuya Nishihara <yuya@tcha.org> [Tue, 16 Feb 2016 21:43:51 +0900] rev 28426
revset: add inspection data to limit() and last() functions We are likely to be interested in how these functions calculate a result set.
Tue, 16 Feb 2016 21:32:00 +0900 revset: stub to add extra data to baseset for better inspection
Yuya Nishihara <yuya@tcha.org> [Tue, 16 Feb 2016 21:32:00 +0900] rev 28425
revset: stub to add extra data to baseset for better inspection We sometimes construct a baseset from filtering result. In that case, a baseset can provide more precise information how it is constructed.
Sat, 13 Feb 2016 20:05:57 +0900 revset: add inspection data to all filter() calls
Yuya Nishihara <yuya@tcha.org> [Sat, 13 Feb 2016 20:05:57 +0900] rev 28424
revset: add inspection data to all filter() calls This is useful for debugging revset construction.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip