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 31143
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 31142
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 31141
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 31140
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 31139
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.
Tue, 21 Feb 2017 20:04:55 +0100 color: update main documentation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 20:04:55 +0100] rev 31138
color: update main documentation Now that the feature no longer lives in the extension, we document it in the help of the core config. This include the new 'ui.color' option introduced in the previous changesets. As a result the color extensions can now be deprecated. This is a documentation patch only; color is still disabled by default.
Tue, 28 Feb 2017 20:12:08 +0100 pager: drop the 'color' dependant code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Feb 2017 20:12:08 +0100] rev 31137
pager: drop the 'color' dependant code The 'color' implementation is in core and no longer wrap '_runcommand'. We drop the extra complexity.
Sat, 25 Feb 2017 19:43:14 +0100 color: cleanup 'debugcolor' logic
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 19:43:14 +0100] rev 31136
color: cleanup 'debugcolor' logic Now that style are carried by the 'ui' object, we no longer need complicated logic to restore the original style. We just need to copy the 'ui' and work on the copied version.
Tue, 21 Feb 2017 18:41:37 +0100 color: move 'debugcolor' into the 'debugcommands' modules
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:41:37 +0100] rev 31135
color: move 'debugcolor' into the 'debugcommands' modules This is the last bits we needed to move out of the extensions. 'hgext/color.py' now only contains logic to changes the default color behavior to 'auto'. However, more cleanups are on the way and we need to document the new config directly in core.
Tue, 28 Feb 2017 11:13:25 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Feb 2017 11:13:25 -0800] rev 31134
merge with stable
Sun, 06 Nov 2016 20:16:54 +0100 color: rename '_styles' to '_defaultstyles' for clarity
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 06 Nov 2016 20:16:54 +0100] rev 31133
color: rename '_styles' to '_defaultstyles' for clarity This should make it clear the dict is only used for new config. Extensions should not modify it directly anyway since we have 'extraloader' logic for loading '_styles' too.
Sun, 06 Nov 2016 20:16:01 +0100 color: move 'styles' definition on the 'ui' object
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 06 Nov 2016 20:16:01 +0100] rev 31132
color: move 'styles' definition on the 'ui' object Same logic as for '_terminfoparams'. The content depends on the config so it should be specific to each 'ui instance.
Sun, 06 Nov 2016 20:10:53 +0100 color: pass 'ui' to 'win32print'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 06 Nov 2016 20:10:53 +0100] rev 31131
color: pass 'ui' to 'win32print' Same logic as before,'win32print' relies on some data we will move on the 'ui' object soon, we update the API beforehand for clarity.
Sat, 25 Feb 2017 15:00:51 +0100 color: move the dict with terminfo parameters on the ui object
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 15:00:51 +0100] rev 31130
color: move the dict with terminfo parameters on the ui object This dictionnary is affected by the content of the config, so we should have one for each ui config. We rename the global dict to '_baseterminfoparams' to make the situation clearer.
Sat, 25 Feb 2017 15:00:44 +0100 color: add ui to effect rendering
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 15:00:44 +0100] rev 31129
color: add ui to effect rendering We'll carry more and more color specific data on the ui object. This will help isolating different color configuration from each other. For example repository config might configure special style that should not affect other ui object. The first step is to make sure the ui object is available were we will needs it.
Sat, 25 Feb 2017 18:34:01 +0100 color: initialize color for the localrepo ui
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 18:34:01 +0100] rev 31128
color: initialize color for the localrepo ui The 'ui' object dedicated to a 'localrepo' is independent from the one available in dispatch (and 'uisetup'). In addition, it is created from the 'baseui' (apparently for good reason). As a result, we need to run the color setup on it after the local repository config is read. This was overlooked when the rest of the initialization changed but did not had impact yet because all setup is still global. We fix it before it is too late.
Sat, 25 Feb 2017 19:44:23 +0100 color: add a 'ui.color' option to control color behavior
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 19:44:23 +0100] rev 31127
color: add a 'ui.color' option to control color behavior This new option control whether or not color will be used. It mirror the behavior of '--color'. I usually avoid adding new option to '[ui]' as the section is already filled with many option. However, I feel like 'color' is central enough to deserves a spot in this '[ui]' section. For now the option is not documented so it is still marked as experimental. Once it get documented and official, we should be able to deprecate the color extensions. There is more cleanup to do before that documentation is written, but we need this option early to made them. Having that option will allow for more cleanup of the initialisation process and proper separation between color configuration.
Tue, 28 Feb 2017 11:42:07 +0100 color: reinvent dictionary
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Feb 2017 11:42:07 +0100] rev 31126
color: reinvent dictionary move the module lever dictionary declaration to a more standard (and practical indentation)
Sun, 19 Feb 2017 01:16:45 +0900 chg: deduplicate error handling of ui.system()
Yuya Nishihara <yuya@tcha.org> [Sun, 19 Feb 2017 01:16:45 +0900] rev 31125
chg: deduplicate error handling of ui.system() This moves 'onerr' handling from low-level util.system() to higher level, which seems better API separation.
Sun, 19 Feb 2017 01:00:10 +0900 chg: refactor ui.system() to be partly overridden
Yuya Nishihara <yuya@tcha.org> [Sun, 19 Feb 2017 01:00:10 +0900] rev 31124
chg: refactor ui.system() to be partly overridden Since fd598149112b changed the signature of ui.system(), chgui.system() should have been updated. This patch factors out the util.system() call so that chg can override how a shell command is executed.
Tue, 21 Feb 2017 18:22:07 +0100 color: have the 'ui' object carry the '_colormode' directly
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:22:07 +0100] rev 31123
color: have the 'ui' object carry the '_colormode' directly Before this changeset, the value was carried by the class to work around limitation of the extensions initialisation. Now that the initialisation is cleanly handled in 'dispatch', we can drop this work around.
Tue, 21 Feb 2017 18:20:12 +0100 color: move triggering of the initialisation logic in core
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:20:12 +0100] rev 31122
color: move triggering of the initialisation logic in core We now run the color initialisation as part of the standard dispatch. This is opening the way for multiple cleanups since we now have access to the multiple 'ui' object and we'll be able to see difference between global and local config. This cleanup will arrive in later changesets. As a side effect, the '--color' flag is now working without the extension. Since we now properly initialize color for each ui idependently, we get a warning message twice.
Tue, 21 Feb 2017 18:09:21 +0100 color: add the definition of '--color' in core
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:09:21 +0100] rev 31121
color: add the definition of '--color' in core If we want to be able to move the initialisation in core, we need core to be aware of that '--color' flag at all time. So we now have the definition in core. That flag is currently unprocessed without the extensions (will be fixed soon). In addition the default value for this flag in core is 'never'. Enabling the extensions change that default value to 'auto'.
Tue, 21 Feb 2017 17:51:43 +0100 color: handle 'ui.plain()' directly in mode setup
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 17:51:43 +0100] rev 31120
color: handle 'ui.plain()' directly in mode setup If 'ui.plain()' is set we should not colorize. We move that logic into the function that determine and setup the color mode. As all other code respect the resulting mode this will be equivalent.
Tue, 21 Feb 2017 17:50:04 +0100 color: move git-subrepo support into the subrepo module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 17:50:04 +0100] rev 31119
color: move git-subrepo support into the subrepo module Now that all ui instance carry a '_colormode' attribute, we can access and comply to it directly in the subrepo code. The actual implementation could probably be a bit smarter, but we stick close to the current one for the sake of simplicity.
Thu, 22 Dec 2016 14:30:46 +0100 color: move 'modesetup' into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 14:30:46 +0100] rev 31118
color: move 'modesetup' into the core module Yet another piece of code moving from the extensions to the module in core!
Thu, 22 Dec 2016 14:17:52 +0100 color: move 'terminfosetup' into the core module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 14:17:52 +0100] rev 31117
color: move 'terminfosetup' into the core module Another step closer to have all the logic living in core
Sat, 25 Feb 2017 21:13:59 -0500 subrepo: run the repo decoders when archiving
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Feb 2017 21:13:59 -0500] rev 31116
subrepo: run the repo decoders when archiving The decoders were already run by default for the main repo, so this seemed like an oversight. The extdiff extension has been using 'archive' since 68822b7cdd01 to support -S, and a colleague noticed that after diffing, making changes, and closing it, the line endings were wrong for the diff-tool modified files in the subrepository. (Files in the parent repo were correct, with the same .hgeol settings.) The editor (Visual Studio in this case) reloads the file, but doesn't notice the EOL change. It still adds new lines with the original EOL setting, and the file ends up inconsistent. Without this change, the first file `cat`d in the test prints '\r (esc)' EOL, but the second doesn't on Windows or Linux.
Sat, 25 Feb 2017 21:44:34 -0500 wix: include the help for pager
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Feb 2017 21:44:34 -0500] rev 31115
wix: include the help for pager Similar (I assume) to 65d2538ac993.
Sun, 26 Feb 2017 10:16:47 -0800 manifest: check 'if x is None' instead of 'if not x'
Durham Goode <durham@fb.com> [Sun, 26 Feb 2017 10:16:47 -0800] rev 31114
manifest: check 'if x is None' instead of 'if not x' The old code here would end up executing __len__ on a tree manifest to determine if 'not _data' was true or not. This was very expensive on large repos. Since this function just cares about memoization, we can just check 'if _data is None' instead and save a bunch of time.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip