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

Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information

From
Shawn O. Pearce <spearce@spearce.org>
Date
Dec 1, 2008, 16:20 UTC
Message-ID
<20081201162011.GI23984@spearce.org>
In-Reply-To
<1228140775-29212-6-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> This implements the server side of protocol extension to show which branch
> the HEAD points at.  The information is sent after the terminating NUL
> that comes after the server capabilities list, to cause older clients to
> ignore it, while allowing newer clients to make use of that information

Ok, not to paint the bikeshed another color or anything ... but can we do something to make this slightly more extensible? I like the "lets hide it behind the NUL" bit a lot better than the prior iteration, but I wonder if we shouldn't do something slightly different.

Maybe we put on the first capability line a flag that lets the client know we have symref data in the advertised list, and then instead of sticking only HEAD into that first ref we put the names of the symrefs after the ref they point to.

So we might see something like:
  xxxx......................... refs/heads/boo\0with-symref\0
  xxxx......................... refs/heads/master\0HEAD\0
  xxxx......................... refs/remotes/origin/HEAD\0refs/remotes/origin/master\0

etc. Its probably harder to produce the output for, but it permits advertising all of the symrefs on the remote side, which may be good for --mirror, among other uses. It also should make it easier to put multiple symrefs down pointing at the same real ref, they could just be a space delimited list stored after the ref name, and if its the first ref in the stream, after the other capability advertisement.

Actually, since the capability line is space delimited and space is not valid in a ref name, we could just include into the capability line like "symref=HEAD", but I still like the idea of listing it after each ref, to reduce the risk of running into pkt-line length limitations.

-- 
Shawn.
Previous: Jakub NarebskiNext: Junio C Hamano
Message 9 of 17 in “Detecting HEAD more reliably while cloning”
  1. 0/6 Detecting HEAD more reliably while cloningJunio C Hamano, Dec 1, 2008
  2. 1/6 get_remote_heads(): refactor code to read "server capabilities"Junio C Hamano, Dec 1, 2008
  3. 2/6 connect.c::read_extra_info(): prepare to receive more than server capabilitiesJunio C Hamano, Dec 1, 2008
  4. 3/6 connect.c::read_extra_info(): find where HEAD points atJunio C Hamano, Dec 1, 2008
  5. 4/6 clone: find the current branch more explicitlyJunio C Hamano, Dec 1, 2008
  6. 5/6 upload-pack: send the HEAD informationJunio C Hamano, Dec 1, 2008
  7. 6/6 clone: test the new HEAD detection logicJunio C Hamano, Dec 1, 2008
  8. Jakub NarebskiDec 1, 2008
  9. Shawn O. PearceDec 1, 2008
  10. Junio C HamanoDec 1, 2008
  11. Jeff KingDec 1, 2008
  12. Junio C HamanoDec 2, 2008
  13. Jeff KingDec 2, 2008
  14. Junio C HamanoDec 2, 2008
  15. Jeff KingDec 2, 2008
  16. Johannes SixtDec 1, 2008
  17. Junio C HamanoDec 2, 2008

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.