Shawn O. Pearce <spearce <at> spearce.org> writes: > +URL Format > +---------- > + > +URLs for Git repositories accessed by HTTP use the standard HTTP > +URL syntax documented by RFC 1738, so they are of the form: > + > + http://<host>:<port>/<path> > + > +Within this documentation the placeholder $GIT_URL will stand for > +the http:// repository URL entered by the end-user. It's worth making clear here that $GIT_URL will be the path to the repository, rather than necessarily just the host upon which the server sits. Perhaps including an example, like http://example:8080/repos/example.git would make it clearer that there can be a path (and so leading to a request like http://example:8080/repos/example.git/info/refs?service=... It's also worth clarifying, therefore, that multiple repositories can be served by the same process (as with the git server today) by using different path(s). And for those that are interested in submodules, it's worth confirming that http://example/repos/master.git/child.git/info/refs?service= will ensure that the repository is the 'child' git rather than anything else. > HEX = [0-9a-f] Is there any reason not to support A-F as well in the hex spec, even if they SHOULD use a-f? This may limit the appeal for some case-insensitive systems. It would also be good to document, like with the git daemon, whether all repositories under a path are exported or only those that have the magic setting in the config like git-daemon-export-ok. Lastly, it would be good to clarify when the result of this GET/POST exchange is a text-based (and encoded in UTF-8) vs when binary data is returned; we don't want to get into the state where we're returning binary data and pretending that it's UTF-8. Alex -- 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