Jonathan Nieder writes:
> Josh Steadmon wrote:
>> On 2018.10.12 16:32, Jonathan Nieder wrote:
>>> Josh Steadmon wrote:
>
For now, I'm going to try adding an --allowed_versions flag for the
remote helpers, but if anyone has a better idea, let me know.
>>>
>>> I forgot to mention: the
Josh Steadmon wrote:
> On 2018.10.12 16:32, Jonathan Nieder wrote:
>> Josh Steadmon wrote:
>>> For now, I'm going to try adding an --allowed_versions flag for the
>>> remote helpers, but if anyone has a better idea, let me know.
>>
>> I forgot to mention: the stateless-connect remote helper
On 2018.10.12 16:32, Jonathan Nieder wrote:
> Josh Steadmon wrote:
>
> > For now, I'm going to try adding an --allowed_versions flag for the
> > remote helpers, but if anyone has a better idea, let me know.
>
> I forgot to mention: the stateless-connect remote helper capability is
> still
Josh Steadmon wrote:
> For now, I'm going to try adding an --allowed_versions flag for the
> remote helpers, but if anyone has a better idea, let me know.
I forgot to mention: the stateless-connect remote helper capability is
still experimental so you're free to change its interface (e.g. to
Hi,
Josh Steadmon wrote:
> So this runs into problems with remote-curl (and possibly other remote
> helpers):
>
> builtin/push.c can declare whatever allowed versions it wants, but those
> are not carried over when remote-curl is started to actually talk to the
> remote. What's worse,
On 2018.10.05 12:25, Stefan Beller wrote:
> > > > I suppose if we are strict about serving from a single endpoint, the
> > > > version registry makes more sense, and individual operations can declare
> > > > acceptable version numbers before calling any network code?
> > >
> > > Ah yeah, that
> > But given that we transport the version in env variables, we'd
> > need to be extra careful if we just did not see the version
> > in the --remote=. above?
>
> Sorry, I'm not sure I understand this. What about env variables requires
> caution?
By locally transporting the version via env
On 2018.10.03 15:47, Stefan Beller wrote:
> On Wed, Oct 3, 2018 at 2:34 PM Josh Steadmon wrote:
> >
> > Is there a method or design for advertising multiple acceptable versions
> > from the client?
>
> I think the client can send multiple versions, looking through protocol.c
> (and not the
On Wed, Oct 3, 2018 at 2:34 PM Josh Steadmon wrote:
>
> I believe that git-upload-archive can still speak version 1 without any
> trouble, but it at least doesn't break anything in the test suite to
> limit this to v0 either.
ok, let me just play around with archive to follow along:
Running
On 2018.10.02 15:28, Stefan Beller wrote:
> On Tue, Oct 2, 2018 at 3:00 PM Josh Steadmon wrote:
> >
> > For services other than git-receive-pack, clients currently advertise
> > that they support the version set in the protocol.version config,
> > regardless of whether or not there is actually an
On Tue, Oct 2, 2018 at 3:00 PM Josh Steadmon wrote:
>
> For services other than git-receive-pack, clients currently advertise
> that they support the version set in the protocol.version config,
> regardless of whether or not there is actually an implementation of that
> service for the given
For services other than git-receive-pack, clients currently advertise
that they support the version set in the protocol.version config,
regardless of whether or not there is actually an implementation of that
service for the given protocol version. This causes backwards-
compatibility problems
12 matches
Mail list logo
