On Thu, Apr 11, 2013 at 9:34 PM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Apr 11, 2013 at 08:52:56AM +0200, Magnus Therning wrote: > >> > The documentation should probably make the use of http.receivepack more >> > clear in this situation. >> >> I think that'd be good. The fact that it wasn't until several mails >> into the thread that anyone thought of the http.receivepack setting >> also suggests that its use is a bit un-intuitive (even though it >> probably makes perfect sense and is a good solution). > > Yeah, I did not even think of http.receivepack because I have never had > to set it before (it was turned on in the original tests that I built > top of). I have the impression that the anonymous-read/authenticated-write > setup you are using has not been all that commonly used. The example in > the manpage dates back to 2009, but it was only in 2012 that we got a > bug report that the client-side authentication handler has problems with > it. Really? I certainly think it deserves a bit more attention than that. It may be that gitosis and other SSH-based solutions have been around longer than git-http-backend, but from what I've understood from reading, it fits very nicely in between git-daemon and the rather heavy SSH-based stuff. >> > But your fix under lighttpd is much better, as it asks for the >> > credentials up front (which means the client does not go to any work >> > creating a packfile just to find out that it does not have access). >> >> Yes, I think it also helps with my particular scenario where new repos >> will be added from time to time. This way there is no second step, >> after `git init`, that must be remembered. > > Yeah, avoiding setting http.receivepack at all is helpful. Though note > that you can also set it in /etc/gitconfig for the whole system at once. Good point. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@xxxxxxxxxxxx jabber: magnus@xxxxxxxxxxxx twitter: magthe http://therning.org/magnus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html