Junio C Hamano <gitster@xxxxxxxxx> 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. -- 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
