Wed, 01 Feb 2017 17:31:05 +0100 debugcommands: extract debuginstall in the debugcommands module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Feb 2017 17:31:05 +0100] rev 30918
debugcommands: extract debuginstall in the debugcommands module
Mon, 13 Feb 2017 16:35:49 +0100 dispatch: load debugcommand before extension
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 13 Feb 2017 16:35:49 +0100] rev 30917
dispatch: load debugcommand before extension Multiple extension will manipulate commands on load, we need the debug command to be loaded before that point.
Mon, 13 Feb 2017 09:44:16 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Feb 2017 09:44:16 -0800] rev 30916
merge with stable
Mon, 13 Feb 2017 11:43:12 -0800 bundle2: fix assertion that 'compression' hasn't been set stable
Siddharth Agarwal <sid0@fb.com> [Mon, 13 Feb 2017 11:43:12 -0800] rev 30915
bundle2: fix assertion that 'compression' hasn't been set `n.lower()` will return `compression`, not `Compression`.
Fri, 10 Feb 2017 18:20:58 +0100 wireproto: properly report server Abort during 'getbundle' stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:20:58 +0100] rev 30914
wireproto: properly report server Abort during 'getbundle' Previously Abort raised during 'getbundle' call poorly reported (HTTP-500 for http, some scary messages for ssh). Abort error have been properly reported for "push" for a long time, there is not reason to be different for 'getbundle'. We properly catch such error and report them back the best way available. For bundle, we issue a valid bundle2 reply (as expected by the client) with an 'error:abort' part. With bundle1 we do as best as we can depending of http or ssh.
Fri, 10 Feb 2017 18:17:20 +0100 getbundle: cleanly handle remote abort during getbundle stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:17:20 +0100] rev 30913
getbundle: cleanly handle remote abort during getbundle bundle2 allow the server to report error explicitly. This was initially implemented for push but there is not reason to not use it for pull too. This changeset add logic similar to the one in 'unbundle' to the client side of 'getbundle'. That logic make sure the error is properly reported as "remote". This will allow the server side of getbundle to send clean "Abort" message in the next changeset.
Fri, 10 Feb 2017 18:06:08 +0100 bundle1: fix bundle1-denied reporting for pull over ssh stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:08 +0100] rev 30912
bundle1: fix bundle1-denied reporting for pull over ssh Changeset b288fb2724bf introduced a config option to have the server deny pull using bundle1. The original protocol has not really been design to allow that kind of error reporting so some hack was used. It turned the hack only works on HTTP and that ssh server hangs forever when this is used. After further digging, there is no way to report the error in a unified way. Using `ooberror` freeze ssh and raising 'Abort' makes HTTP return a HTTP-500 without further details. So with sadness we implement a version that dispatch according to the protocol used. Now the error is properly reported, but we still have ungraceful abort after that. The protocol do not allow anything better to happen using bundle1.
Fri, 10 Feb 2017 18:06:12 +0100 bundle-tests: operate from outside a repository stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:12 +0100] rev 30911
bundle-tests: operate from outside a repository We are about to add a test for ssh pull/cloning being denied because of bundle1 usage. For this, it is cleaner to not operate from the clone using http. So we update the test beforehand for clarity. This is more churns that what I'm happy to see on stable, but the rests of the series is worth it in my opinion.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip