Re: [PATCH 2/2] connect: know that zero-ID is not a ref

From: Jeff King <peff@peff.net>
Date: Sep 2, 2016, 23:19 UTC
Message-ID: <20160902231928.pcuket2yrypbxeir@sigill.intra.peff.net>
In-Reply-To: <84df7985-6c87-9485-261c-e8e9a3bbab7b@google.com>

On Fri, Sep 02, 2016 at 03:11:16PM -0700, Jonathan Tan wrote:

Show 17 quoted lines

> On 09/02/2016 01:13 PM, Jeff King wrote:
> > On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
> > > (git-daemon should probably also be changed to serve zero IDs, but such
> > > a change can be considered independently from this change; even if both
> > > the client and server changes were made in one commit, it is nearly
> > > impossible that all Git installations are updated at the same time - an
> > > updated client would still need to deal with unupdated servers and vice
> > > versa.)
> > 
> > I'm really not sure what you mean here. How does git-daemon enter into
> > this at all?
> 
> I was comparing the behavior of git daemon and jgit daemon - when serving
> the same repository, the former does not send the zero ID and
> capabilities^{} line, whereas the latter does; and I was stating that git
> daemon's behavior should be changed to JGit's behavior, but not necessarily
> immediately.

Ah, I see. I was confused because it's git-upload-pack, not git-daemon, which would be modified (git-daemon may also spawn other tools like receive-pack, which _does_ already have this behavior).

I remain unconvinced that we should transition to the JGit behavior on the server side (as opposed to "fixing" the documentation). However, given that JGit versions with this behavior are in the wild, it seems like a no-brainer to make the receiver more liberal (i.e., this series).

-Peff