From: Andreas Ericsson Date: Wed, 24 Oct 2007 09:03:24 GMT Subject: Re: Git public repository naming convention Message-ID: <471F0A5C.6090705@op5.se> In-Reply-To: Benoit SIGOURE wrote: > [CC: Git-ML] > > On Oct 24, 2007, at 9:51 AM, Jim Meyering wrote: >> Benoit SIGOURE wrote: >>>> On Oct 24, 2007, at 12:28 AM, Paul Eggert wrote: >>>>> Index: gnulib.html >>>>> =================================================================== >>>>> RCS file: /web/gnulib/gnulib/gnulib.html,v >>>>> retrieving revision 1.13 >>>>> retrieving revision 1.16 >>>>> diff -p -u -r1.13 -r1.16 >>>>> --- gnulib.html 22 Oct 2007 21:41:43 -0000 1.13 >>>>> +++ gnulib.html 23 Oct 2007 22:22:18 -0000 1.16 >>>>> @@ -57,14 +57,20 @@ You can also view the git://git.sv.gnu.org/gnulib.git". Oddly enough, whether you add the > `.git' or not doesn't seem to change anything. > > The documentation (Documentation/urls.txt) only shows examples of the > form `git://host.xz/path/to/repo.git/'. So do > Documentation/core-tutorial.txt, Documentation/git-clone.txt and > Documentation/repository-layout.txt (among others). > > Maybe the Git gurus will be able to shed some light on this issue. > The dwimmery is handled on the server side and always happens unless git-upload-pack gets the --strict flag. In git-daemon, this option is called "--strict-paths". git clone http://anything means the request doesn't end up in the hands of git-upload-pack, so the DWIM code in path.c::enter_repo() is never run. Letting http-fetch re-implement the same dwimmery, using a trial/error approach, but saving the correct URL in the remotes config, should solve this problem, although it will be quite slow on high-latency networks. Perhaps that doesn't matter, as it should only be an issue for the original clone. The suffixes to try are these: const char *suffix[] = { ".git/.git", "/.git", ".git", "", NULL }; I believe gitweb mimics this behaviour. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231