git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/3] upload-pack: send the HEAD information

From
Jeff King <peff@peff.net>
Date
Sep 8, 2013, 07:13 UTC
Message-ID
<20130908071359.GJ14019@sigill.intra.peff.net>
In-Reply-To
<xmqqsixhyhan.fsf@gitster.dls.corp.google.com>
On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote:
> I think it is perfectly fine to expose _only_ HEAD now, and wait
> until we find a good reason that we should send this information for
> other symbolic refs in the repository.
Yeah, I agree with that.
Show 17 quoted lines
> However, because we already anticipate that we may find such a good
> reason later, on-the-wire format should be prepared to support such
> later enhancement.  I think sending
> 
> 	symref=HEAD:refs/heads/master
> 
> is probably one good way to do so, as Peff suggested in that old
> thread ($gmane/102070; note that back then this wasn't suggested as
> a proper capability so the exact format he suggests in the message
> is different).  Then we could later add advertisements for other
> symbolic refs if we find it necessary to do so, e.g.
> 
> 	symref=HEAD:refs/heads/master
>         symref=refs/remotes/origin/HEAD:refs/remotes/origin/master
> 
> (all on one line together with other capabilities separated with a
> SP in between).

It somehow feels a little weird to me that we would output the information about refs/foo on the HEAD line. A few possible issues (and I am playing devil's advocate to some degree here):

  1. What if we have a large number of symrefs? Would we run afoul of
     pkt-line length limits?
  2. What's the impact of having to display all symrefs on the first
     line, before we output other refs? Right now we can just stream out
     refs as we read them, but we would have to make two passes (and/or
     cache them all) to find all of the symrefs before we start
     outputting. Will the extra latency ever matter?

What do you think about teaching git to read extra data after "\0" for _every_ ref line? And then ref advertisement might look something like:

  <sha1> HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n
  <sha1> refs/heads/master\n
  <sha1> refs/heads/my-alias\0symref=refs/heads/master

That would leave us future room for more ref annotations if we should want them, and I think (but haven't tested) that existing receivers should ignore everything after the NUL.

-Peff
Previous: Junio C HamanoNext: Jeff King
Message 6 of 32 in “Unconfuse git clone when two branches at are HEAD.”
  1. 0/3 Unconfuse git clone when two branches at are HEAD.Andreas Krey, Sep 6, 2013
  2. 1/3 upload-pack: send the HEAD informationAndreas Krey, Sep 6, 2013
  3. Junio C HamanoSep 6, 2013
  4. Andreas KreySep 6, 2013
  5. Junio C HamanoSep 6, 2013
  6. Jeff KingSep 8, 2013
  7. Jeff KingSep 8, 2013
  8. Junio C HamanoSep 8, 2013
  9. 0/6 Removing the guesswork of HEAD in "clone"Junio C Hamano, Sep 18, 2013
  10. 1/6 upload-pack.c: do not pass confusing cb_data to mark_our_ref()Junio C Hamano, Sep 18, 2013
  11. 2/6 upload-pack: send symbolic ref information as capabilityJunio C Hamano, Sep 18, 2013
  12. Junio C HamanoSep 18, 2013
  13. 3/6 upload-pack: send non-HEAD symbolic refsJunio C Hamano, Sep 18, 2013
  14. 4/6 connect.c: make parse_feature_value() staticJunio C Hamano, Sep 18, 2013
  15. 5/6 connect: annotate refs with their symref information in get_remote_head()Junio C Hamano, Sep 18, 2013
  16. 6/6 clone: test the new HEAD detection logicJunio C Hamano, Sep 18, 2013
  17. 2/3 connect.c: save symref info from server capabilitiesAndreas Krey, Sep 6, 2013
  18. Junio C HamanoSep 6, 2013
  19. Andreas KreySep 6, 2013
  20. Junio C HamanoSep 6, 2013
  21. 3/3 clone: test the new HEAD detection logicAndreas Krey, Sep 6, 2013
  22. Philip OakleySep 6, 2013
  23. Junio C HamanoSep 6, 2013
  24. Philip OakleySep 6, 2013
  25. Junio C HamanoSep 7, 2013
  26. Philip OakleySep 7, 2013
  27. Junio C HamanoSep 8, 2013
  28. Philip OakleySep 8, 2013
  29. Junio C HamanoSep 9, 2013
  30. Andreas KreySep 9, 2013
  31. Philip OakleySep 9, 2013
  32. Junio C HamanoSep 9, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.