On Mon, Dec 01, 2008 at 06:12:54AM -0800, Junio C Hamano wrote:
> + packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
> + 0, capabilities, 0, target);
Yuck. My two complaints are:
(1) this implicitly handles only the HEAD symref. I don't think any
others are in common use, but the rest of git handles arbitrary
symrefs just fine. It would be a shame to needlessly limit the
protocol. Can we at least make it <ref>:<ref> to allow later
expansion to other symrefs?
(1a) As a follow-on to that, because the client is not requesting
anything, how would we ask for other symrefs if we want to do so
later? I think it would be nice to eventually allow copying of
arbitrary symrefs within the refs/* hierarchy (e.g.,
project-specific branch aliases). Sending all symrefs right off
the bat is potentially large and wasteful.
(2) You've used up the first such expansion slot forever. Now it's "if
I want to tell you the symref, there is an extra slot, and
otherwise none". But if we ever want to use the _next_ slot, then
you will always have to send this slot (blank, I guess?). It gets
even more complicated if you ever want to an arbitrary number of
symref mappings. Maybe a short header to say "this slot contains a
symref target"?
So (1) and (2) together would make it something like:
<capabilities>\0
symref HEAD:refs/heads/master\0
symref refs/heads/alias:refs/heads/branch\n
which would make adding any new features in the expansion slots easier.
But that still doesn't address (1a). I really like the other proposal a
lot better.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
