Thu, 05 Feb 2015 16:03:26 -0800 bundlerepo: keep track of the original bundle object
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 16:03:26 -0800] rev 24072
bundlerepo: keep track of the original bundle object Bundlerepo should always close() the object that it receives from exchange.readbundle(). When bundle2 support is added in a later diff, self.bundle will be overwritten to be the changegroup part instead of the entire bundle unpacker.
Thu, 05 Feb 2015 15:56:50 -0800 bundle2.unbundle20: add compressed() method
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:56:50 -0800] rev 24071
bundle2.unbundle20: add compressed() method Bundlerepo uses the compressed() method to determine whether it should write an uncompressed temporary file. Since we don't support compressed bundle2 files at the moment, make this method return true.
Thu, 05 Feb 2015 15:52:57 -0800 bundle2.unpackermixin: default value for seek() whence parameter
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:52:57 -0800] rev 24070
bundle2.unpackermixin: default value for seek() whence parameter The contract for seek() includes seeking to an offset from the beginning of the file when whence is omitted; put this implementation in compliance.
Fri, 06 Feb 2015 23:40:46 +0100 windows: adjust doc string and comments of posixfile()
Adrian Buehlmann <adrian@cadifra.com> [Fri, 06 Feb 2015 23:40:46 +0100] rev 24069
windows: adjust doc string and comments of posixfile() The doc string of osutil.posixfile includes (line 611): "On error, this function may raise either a WindowsError or an IOError." which is most likely correct, but does not fit for this function here anymore, as we do fold WindowsError to IOError here specifically. And this function is now a bit more than just an exception-wrapper, as it has been expanded to additionally sanitize the unloved seek/tell behavior of Windows. (Self-disclosure: This patch is entirely untested at the time of its publication, as I'm currently not using this version myself. I send it in hopes that it will reduce potential future confusion. CC-ing Matt Harbison)
Wed, 04 Feb 2015 14:11:45 -0800 color: support a different color mode when the pager is active
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Feb 2015 14:11:45 -0800] rev 24068
color: support a different color mode when the pager is active MSYS on Windows has a terminal that supports the "win32" color mode (which "auto" properly detects for us). However, a popularily configured pager in that environment (GNU less) only supports the "ansi" color mode. This patch teaches color about a new config option: pagermode. It behaves like "mode" but is only consulted when the pager is active for the current command. MSYS users can now set "pagermode = ansi" and get a colorful experience that just works. Previously, MSYS users would have to live without color when using GNU less as the pager, would have to manually configure the pager to attend every command, or would have gibberish if "ansi" was used without the pager.
Fri, 06 Feb 2015 12:09:09 -0800 pager: ensure wrapped dispatch._runcommand runs before color's
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:09:09 -0800] rev 24067
pager: ensure wrapped dispatch._runcommand runs before color's An upcoming patch will teach color to potentially act differently if the pager is active. Since both extensions wrap the same function (dispatch._runcommand) to change behavior, we must guarantee that pager's wrapped function runs before color's so color may read the breadcrumb left by pager.
Fri, 06 Feb 2015 12:07:56 -0800 pager: set an attribute on ui indicating that a pager is active
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:56 -0800] rev 24066
pager: set an attribute on ui indicating that a pager is active A subsequent patch will teach the color extension to do different things depending on whether a pager is active. This patch leaves a breadcrumb on the ui instance to allow it do that that.
Fri, 06 Feb 2015 12:07:32 -0800 extensions: support callbacks after another extension loads
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:32 -0800] rev 24065
extensions: support callbacks after another extension loads An upcoming patch will introduce a dependency between the color and pager extensions. To prepare for this, we teach extensions how to register callbacks that can execute when another extension loads. This patch is based on code provided by Matt Mackall. But significant parts have changed (such as the ability to register multiple callbacks and the change in behavior to always call a callback). I believe that always firing the callback is a good practice. I think the common use for this feature will be for extensions to say "run this one-time setup code, after this other extension if possible." Always running the callback will facilitate this.
Fri, 06 Feb 2015 21:53:39 +0900 log: fix --follow null parent not to include revision 0
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 21:53:39 +0900] rev 24064
log: fix --follow null parent not to include revision 0 If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null, only revision 0 was visible. Because 'null' should not be listed implicitly, "log --follow" (without -r) should be empty if p1 is null. Test of "hg grep -f" is added for cmdutil.walkchangerevs().
Fri, 06 Feb 2015 00:22:20 +0900 cmdutil: have walkchangerevs utilize common function to build revs
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 00:22:20 +0900] rev 24063
cmdutil: have walkchangerevs utilize common function to build revs
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip