Fri, 11 Nov 2016 13:06:05 +1100 color: show mode warning based on ui.formatted
Xidorn Quan <me@upsuper.org> [Fri, 11 Nov 2016 13:06:05 +1100] rev 30377
color: show mode warning based on ui.formatted ui.interactive is only for input and ui.formatted is for output.
Thu, 10 Nov 2016 15:14:05 -0500 protocol: drop unused import of zlib
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 15:14:05 -0500] rev 30376
protocol: drop unused import of zlib Something weird is happening that breaks pyflakes installed via 'pip install --user'. I haven't had a chance to finish debugging this, but this at least fixes the build.
Tue, 08 Nov 2016 22:41:45 +0900 hook: lower inflated use of sys.__stdout__ and __stderr__
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Nov 2016 22:41:45 +0900] rev 30375
hook: lower inflated use of sys.__stdout__ and __stderr__ They were introduced at 9f76df0edb7d, where sys.stdout could be replaced by sys.stderr. After that, we've changed the way of stdout redirection by afccc64eea73, so we no longer need to reference the original __stdout__ and __stderr__ objects. Let's move away from using __std*__ objects so we can simply wrap sys.std* objects for Python 3 porting.
Tue, 08 Nov 2016 22:22:22 +0900 hook: flush stdout before restoring stderr redirection
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Nov 2016 22:22:22 +0900] rev 30374
hook: flush stdout before restoring stderr redirection There was a similar issue to 8b011ededfb2. If an in-process hook writes to stdout, the data may be buffered. In which case, stdout must be flushed before restoring its file descriptor. Otherwise, remaining data would be sent over the ssh wire and corrupts the protocol. Note that this is a different redirection from the one I've just removed.
Thu, 20 Oct 2016 22:39:59 +0900 hook: do not redirect stdout/err/in to ui while running in-process hooks (BC)
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Oct 2016 22:39:59 +0900] rev 30373
hook: do not redirect stdout/err/in to ui while running in-process hooks (BC) It was introduced by a59058fd074a to address command-server issues. After that, I've made a complete fix by 69f86b937035, so we don't need to replace sys.stdio objects to protect the IPC channels. This change means we no longer see data written to sys.stdout/err by an in-process hook on command server. I think that's okay because the canonical way is to use ui functions and in-process hooks should respect the Mercurial API. This will help Python 3 porting, where sys.stdout is TextIO but ui.fout is BytesIO.
Thu, 10 Nov 2016 02:21:15 -0800 merge: change modified indicator to be 20 bytes
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:21:15 -0800] rev 30372
merge: change modified indicator to be 20 bytes Previously we indicated that the .hgsubstate file was dirty by adding a '+' to the end of its hash in the wctx manifest. This made is complicated to have new manifest implementations that rely on the node length being fixed. In previous patches we added added and modified node placeholders, so let's use those to indicate dirty here as well. It doesn't look like anything ever depended on this '+' (aside from it being different to the parent), so nothing else needed to change here.
Thu, 10 Nov 2016 02:19:16 -0800 dirstate: change added/modified placeholder hash length to 20 bytes
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:19:16 -0800] rev 30371
dirstate: change added/modified placeholder hash length to 20 bytes Previously the added/modified placeholder hash for manifests generated from the dirstate was a 21byte long string consisting of the p1 file hash plus a single character to indicate an add or a modify. Normal hashes are only 20 bytes long. This makes it complicated to implement more efficient manifest implementations which rely on the hashes being fixed length. Let's change this hash to just be 20 bytes long, and rely on the astronomical improbability of an actual hash being these 20 bytes (just like we rely on no hash every being the nullid). This changes the possible behavior slightly in that the hash for all added/modified entries in the dirstate manifest will now be the same (so simple node comparisons would say they are equal), but we should never be doing simple node comparisons on these nodes even with the old hashes, because they did not accurately represent the content (i.e. two files based off the same p1 file node, with different working copy contents would have the same hash (even with the appended character) in the old scheme too, so we couldn't depend on the hashes period).
Thu, 10 Nov 2016 02:17:22 -0800 dirstate: change placeholder hash length to 20 bytes
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:17:22 -0800] rev 30370
dirstate: change placeholder hash length to 20 bytes Previously the new-node placeholder hash for manifests generated from the dirstate was a 21byte long string of "!" characters. Normal hashes are only 20 bytes long. This makes it complicated to implement more efficient manifest implementations which rely on the hashes being fixed length. Let's change this hash to just be 20 bytes long, and rely on the astronomical improbability of an actual hash being 20 "!" bytes in a row (just like we rely on no hash ever being the nullid). A future diff will do this for added and modified dirstate markers as well, so we're putting the new newnodeid in node.py so there's a common place for these placeholders.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip