Mon, 13 Feb 2017 14:05:24 +0100 share: add --relative flag to store a relative path to the source
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Mon, 13 Feb 2017 14:05:24 +0100] rev 31133
share: add --relative flag to store a relative path to the source Storing a relative path the source repository is useful when exporting repositories over the network or when they're located on external drives where the mountpoint isn't always fixed. Currently, Mercurial interprets paths in `.hg/shared` relative to $PWD. I suspect this is very much unintentional, and you have to manually edit `.hg/shared` in order to trigger this behaviour. However, on the off chance that someone might rely on it, I added a new capability called 'relshared'. In addition, this makes earlier versions of Mercurial fail with a graceful error. I should note that I haven't tested this patch on Windows.
Wed, 15 Feb 2017 11:49:12 -0800 minirst: support passing admonitions into findadmonitions() and parse()
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 15 Feb 2017 11:49:12 -0800] rev 31132
minirst: support passing admonitions into findadmonitions() and parse() This will allow consumers to declare a custom list of admonitions to parse. Without this patch, custom admonitions would get removed when prunecomments() is run. We could add an argument controlling whether prunecomments() is run. However, it is better to convert the "paragraph" block to an "admonition" block so consumers don't have to parse for custom admonitions.
Wed, 15 Feb 2017 11:47:14 -0800 minirst: dynamically compile admonitions regexp
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 15 Feb 2017 11:47:14 -0800] rev 31131
minirst: dynamically compile admonitions regexp Currently, parsing admonitions uses a static regular expression created from a pre-defined list of admonitions. A future patch will introduce a feature that needs to parse custom admonitions. Prepare for this by compiling the admonitions regular expression during each function invocation. Strictly speaking, there is a slight performance loss here. But we only run this code as part of displaying help text. I don't think the loss will be noticeable and I don't think we care if it were.
Wed, 15 Feb 2017 16:42:17 -0800 minirst: detect bullet lists using asterisks
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 15 Feb 2017 16:42:17 -0800] rev 31130
minirst: detect bullet lists using asterisks Previously, the "bullet" regular expression excluded the asterisk ('*') as a character denoting a bulleted list. Why I'm not sure because the asterisk seems to be the canonical bullet character in reST these days. This patch makes asterisk-prefixed lines parse as bulleted lists.
Wed, 01 Mar 2017 20:22:04 +0100 color: update the help table
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Mar 2017 20:22:04 +0100] rev 31129
color: update the help table We also need to reference the new topic in the great old help table.
Sat, 25 Feb 2017 14:09:55 +0900 ui: remove superfluous indent in _write()
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 14:09:55 +0900] rev 31128
ui: remove superfluous indent in _write()
Sat, 18 Feb 2017 17:37:52 +0900 smartset: reorder initialization of baseset in more intuitive way
Yuya Nishihara <yuya@tcha.org> [Sat, 18 Feb 2017 17:37:52 +0900] rev 31127
smartset: reorder initialization of baseset in more intuitive way What we want to do is to assign either _set or _list per the given data type.
Tue, 28 Feb 2017 20:23:10 +0100 config: update the Windows example config file
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Feb 2017 20:23:10 +0100] rev 31126
config: update the Windows example config file We move from the color extensions to the 'ui.color' config.
Tue, 21 Feb 2017 22:53:38 +0100 help: use 'churn' instead of 'color' as an example extension
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 22:53:38 +0100] rev 31125
help: use 'churn' instead of 'color' as an example extension The 'color' extensions is now deprecated.
Tue, 21 Feb 2017 22:17:33 +0100 config: suggest the 'ui.color' instead of the 'color' extension
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 22:17:33 +0100] rev 31124
config: suggest the 'ui.color' instead of the 'color' extension The extensions is deprecated now so we should offer the core way to handle color instead.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip