Shawn Pearce writes:
> On Fri, Aug 10, 2012 at 2:50 PM, Jeff King wrote:
>> On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
>>
>>> When evaluating a change in the interoperability area, it does not
>>> add much more confidence to the correctness that the change has been
>>> in us
On Fri, Aug 10, 2012 at 2:50 PM, Jeff King wrote:
> On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
>
>> When evaluating a change in the interoperability area, it does not
>> add much more confidence to the correctness that the change has been
>> in use for months with the same par
On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
> When evaluating a change in the interoperability area, it does not
> add much more confidence to the correctness that the change has been
> in use for months with the same partner than that it has been used
> to talk to many differe
Jeff King writes:
> Yes, I think that is all that is necessary to fix the immediate issue.
> The protocol-capabilities document talks about what to do when
> include-tag is not available ("SHOULD issue a subsequent fetch to
> acquire the tags that include-tag would have otherwise given the
> clie
On Fri, Aug 10, 2012 at 02:25:51PM -0700, Junio C Hamano wrote:
> > I don't think there's any bug here. They are all of a class of features
> > where the client can handle the case where the server simply ignores the
> > request. However it is certainly food for thought if we are considering
> > t
Jeff King writes:
> On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
>
>> > Thanks for the data point. I knew you guys ran some custom code, so I
>> > wasn't sure how widespread this is. The fact that other dulwich-based
>> > servers would see the same issue makes me doubly sure tha
Dave Borowitz writes:
> You may also notice in that code a set of innocuous_capabilities,
> which IIRC is the complete set of capabilities, at the time of
> writing, that the C git client may send without the server advertising
> them. Such a set (painstakingly assembled, I assure you :) may be
>
Jeff King writes:
> Thanks for confirming the push side. I have been running with the patch
> for months, but only recently happened to try cloning something from
> code.google.com.
Note that I didn't "confirm" the fix. I only confirmed the
existence of the breakage (not that I have any reason
On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
> > Thanks for the data point. I knew you guys ran some custom code, so I
> > wasn't sure how widespread this is. The fact that other dulwich-based
> > servers would see the same issue makes me doubly sure that my fix is the
> > right
On Fri, Aug 10, 2012 at 11:08 AM, Jeff King wrote:
> On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
>
>> > I asked the folks who run code.google.com and they are indeed seeing
>> > something like these in their logs:
>> >
>> > >> Client asked for capability agent=git/1.7.12.rc2.79
On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
> > I asked the folks who run code.google.com and they are indeed seeing
> > something like these in their logs:
> >
> > >> Client asked for capability agent=git/1.7.12.rc2.79.g86c1702 that was
> > not advertised.
>
> FWIW, this err
On Fri, Aug 10, 2012 at 8:37 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Ugh, the jk/version-string topic breaks fetching from Google Code. With
>> my patch, the client unconditionally sends an "agent=foo" capability,
>> but the server does not like seeing the unknown capability and ends t
On Fri, Aug 10, 2012 at 08:34:45AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ugh, the jk/version-string topic breaks fetching from Google Code. With
> > my patch, the client unconditionally sends an "agent=foo" capability,
> > but the server does not like seeing the unknown capabili
Jeff King writes:
> Ugh, the jk/version-string topic breaks fetching from Google Code. With
> my patch, the client unconditionally sends an "agent=foo" capability,
> but the server does not like seeing the unknown capability and ends the
> connection (I'm guessing with some kind of internal excep
Jeff King writes:
> Ugh, the jk/version-string topic breaks fetching from Google Code. With
> my patch, the client unconditionally sends an "agent=foo" capability,
> but the server does not like seeing the unknown capability and ends the
> connection (I'm guessing with some kind of internal excep
On Fri, Aug 03, 2012 at 12:19:16PM -0400, Jeff King wrote:
> Instead of having the client advertise a particular version
> number in the git protocol, we have managed extensions and
> backwards compatibility by having clients and servers
> advertise capabilities that they support. This is far more
16 matches
Mail list logo
