On Thu, Apr 11, 2013 at 9:34 PM, Jeff King <p...@peff.net> 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
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.
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html