On Fri, Sep 21, 2012 at 10:34:22AM -0700, Junio C Hamano wrote:
> >> > I'm half-tempted to just drop the config entirely, leave
> >> > GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
> >>
> >> Sounds like a very attractive minimalistic way to go forward. We
> >> can alway
Jeff King writes:
> On Thu, Sep 20, 2012 at 02:15:20PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I'm half-tempted to just drop the config entirely, leave
>> > GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
>>
>> Sounds like a very attractive minimalis
On Thu, Sep 20, 2012 at 02:15:20PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm half-tempted to just drop the config entirely, leave
> > GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
>
> Sounds like a very attractive minimalistic way to go forward. We
>
Jeff King writes:
> I'm half-tempted to just drop the config entirely, leave
> GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
Sounds like a very attractive minimalistic way to go forward. We
can always add per-remote configuration when we find it necessary,
but once we
On Thu, Sep 20, 2012 at 11:36:34AM -0700, Junio C Hamano wrote:
> >> What would the user experience be when we introduce "even smarter"
> >> http server protocol extension? Will we add remote.foo.starterhttp?
> >
> > I would hope that it would actually be negotiated reliably at the
> > protocol l
Jeff King writes:
> On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I added the config item as remote.foo.smarthttp. You could also allow
>> > "http.$url.smart" (and just "http.smart", for that matter), which could
>> > be more flexible if you have
On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I added the config item as remote.foo.smarthttp. You could also allow
> > "http.$url.smart" (and just "http.smart", for that matter), which could
> > be more flexible if you have multiple remotes pointing t
Jeff King writes:
> I added the config item as remote.foo.smarthttp. You could also allow
> "http.$url.smart" (and just "http.smart", for that matter), which could
> be more flexible if you have multiple remotes pointing to the same
> broken server.
What would the user experience be when we intr
Usually there is no need for users to specify whether an
http remote is smart or dumb; the protocol is designed so
that a single initial request is made, and the client can
determine the server's capability from the response.
However, some misconfigured dumb-only servers may not like
the initial r
9 matches
Mail list logo
