Josh Steadmon writes:
> Yes, the version on my desktop sends version=2 when archiving:
>
> ∫ which git
> /usr/bin/git
> ∫ git --version
> git version 2.19.0.605.g01d371f741-goog
> ∫ GIT_TRACE_PACKET=${HOME}/server_trace git daemon \
> --enable=upload-archive \
>
On 2018.09.27 15:20, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > 1. Clients sending version=2 when they do not, in fact, speak protocol
> > v2 for a service is a (serious) bug. (Separately from this
> > series) we should fix it.
> >
> > 2. That bug is already in the wild,
Jonathan Nieder writes:
> 1. Clients sending version=2 when they do not, in fact, speak protocol
> v2 for a service is a (serious) bug. (Separately from this
> series) we should fix it.
>
> 2. That bug is already in the wild, alas. Fortunately the semantics of
> GIT_PROTOCOL as a
On 2018.09.27 11:20, Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
> >
> > This is the second version of my series to add a new protocol v2 command
> > for archiving, with support for HTTP(S).
> >
> > NEEDSWORK: a server built with this series is not
Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>> I've been discussing workarounds for this with Jonathan Nieder, but
>> please let me know if you have any suggestions for v3 of this series.
>
> Care to open the discussion to the list? What are the different
>
On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>
> This is the second version of my series to add a new protocol v2 command
> for archiving, with support for HTTP(S).
>
> NEEDSWORK: a server built with this series is not backwards-compatible
> with clients that set GIT_PROTOCOL=version=2 or
This is the second version of my series to add a new protocol v2 command
for archiving, with support for HTTP(S).
NEEDSWORK: a server built with this series is not backwards-compatible
with clients that set GIT_PROTOCOL=version=2 or configure
protocol.version=2. The old client will
7 matches
Mail list logo
