On 2018.09.27 15:20, Junio C Hamano wrote:
> Jonathan Nieder <[email protected]> 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 list of key/value pairs is well defined. So we
> > have choices of (a) bump version to version=3 (b) pass another
> > value 'version=2:yesreallyversion=2' (c) etc.
> >
> > 3. This is likely to affect push, too.
>
> Do you mean that existing "git push", "git fetch" and "git archive"
> sends version=2 even when they are not capable of speaking protocol
> v2? I thought that "git archive [--remote]" was left outside of the
> protocol update (that was the reason why the earlier attempt took a
> hacky route of "shallow clone followed by local archive"), so there
> is no "git archive" in the wild that can even say "version=$n"
> (which requires you to be at least version=1)?
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 \
--base-path=${HOME}/src/bare-repos &
[1] 258496
∫ git archive --remote git://localhost/test-repo.git HEAD >! test.tar
∫ grep version ~/server_trace
15:31:22.377869 pkt-line.c:80 packet: git<
git-upload-archive /test-repo.git\0host=localhost\0\0version=2\0
