adding and updating an example..
From: "Philip Oakley" <philipoak...@iee.org>
been trying to keep up...
From: "Jeff King" <p...@peff.net>
On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote:
The just-HEAD case could look like:
This patch does work, in the sense that upload-pack advertises the
unborn HEAD symref. But the client doesn't actually do anything with it.
The capability parsing happens in get_remote_heads(), which passes the
data out by adding an annotation to the "struct ref" list. But of course
we have no HEAD ref to annotate.
So either get_remote_heads() would have to start returning a bogus HEAD
ref (with a null sha1, I guess, which all callers would have to
recognize). Or clone (and probably "remote set-head -a") would have to
start reaching across the transport-module boundary and asking for any
symref values for "HEAD". I'm not excited about more special-casing of
"HEAD", though. In theory we'd want this for other symrefs in the long
run, and it would be nice if clients were ready to handle that (even if
the protocol isn't quite there).
I dunno. I was thinking there might be a quick tweak, but I'm wondering
if this arcane case is worth the restructuring we'd have to do to
support it. It only comes up when you've moved the server repo's HEAD to
an unborn branch _and_ you have other refs (since otherwise we don't
even send capabilities at all!).
-Peff
My original comment regarding Felix's report was based on when I was
looking at the bundle code's disambiguation of refs which matched HEAD's
sha1. Hence I had a mis-remembered impression that the HEAD - symref
matching was avaibable.
At that time, Junio had suggested that, at least in the bundle file, the
HEAD symref could be advertised immediately after a nul on the ref line.
At least for regular git, the sha1and symref value would included in the
read line, and the current string processing [1] would not notice the
extra symref data. This extra data could then be read (if present) from
the end of the line, and the HEAD symref set.
What I then noticed (but didn't report to the list) was the option of
adding that extra info to the PKLINE protocol.
<from my notes>
In technical\pack-protocol.txt #L136;158-160
Reference Discovery:
If HEAD is a valid ref, HEAD MUST appear as the first advertised
ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the
advertisement list at all, but other refs may still appear.
-
So, (for both upload pack, and bundle refs) the place to hide the HEAD is
after the later ref that HEAD points to.
e.g.(updating the example at #L147):
00441d3fcd5ced445d1abc402225c0b8a1299641f497
refs/heads/integration\0HEAD[LF]
The potential issue is if there is a passed ref that is HEAD, but that
HEAD itself isn't passed (especially for bundle)
<\from my notes>
--
However given the discussion about an unborn HEAD, the option here would
be to also pass the NULL sha for the symref and then add the annotation
'HEAD' after an extra \0, in the same way that an active symref could be
annotated with the '\0HEAD'. This would kill two birds with one stone!
These are still protocol changes but should squeeze into the existing
processing using the \0 trick.
In the absence of the information, and the multi-use of the warning
function, the current message is possible the best we can get.
Philip
[1] the question would be whether other git versions also use the same
string processing so could be 'fooled' in the same way? I'd be interested
to know if that was a possibility.
Updating the original example with the suggestion of adding the unborn ref
and a \0HEAD marker (sort order may be an issue if it is the first entry
which 'clashes' with the capability string... - I've been lenient here)
$ git ls-remote git://github.com/passcod/UPPERCASE-NPM.git
efc7dbfd6ca155d5d19ce67eb98603896062f35a refs/heads/MASTER
0000000000000000000000000000000000000000 refs/heads/master\0HEAD
e60ea8e6ec45ec45ff44ac8939cb4105b16477da refs/pull/1/head
f35a73dcb151d336dc3d30c9a2c7423ecdb7bd1c refs/pull/2/head
0d9b3a1268ff39350e04a7183af0add912b686e6 refs/tags/V1.0.0
efc7dbfd6ca155d5d19ce67eb98603896062f35a refs/tags/V1.0.1
--
Philip
