Subject: Re: Git public repository naming convention

From: Andreas Ericsson <[email-masked]>
Date: Wed, 24 Oct 2007 11:03:24 +0200

Benoit SIGOURE wrote:
> [CC: Git-ML]
> 
> On Oct 24, 2007, at 9:51 AM, Jim Meyering wrote:
>> Benoit SIGOURE <[email-masked]> 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 <a href="MODULES.h
>>>>>  anonymous <a href='http://git.or.cz/'>Git</a>, using the following
>>>>>  shell command:</p>
>>>>>
>>>>> -<pre><samp>git clone git://git.savannah.gnu.org/gnulib.git
>>>>> +<pre><samp>git clone git://git.savannah.gnu.org/gnulib
>>>>>  </samp></pre>
>>>
>>> Is there any reason why this has changed?  I learned (the hard way)
>>> that for bare public repositories, it's better to stick to what turns
>>> out to be more than a naming convention of `project.git'.  I don't
>>
>> What are the consequences of not doing that?
> 
> You can't git-clone the remote repo because it tries to fetch the wrong 
> URL (if the url isn't of the form `foo.git' it will try to fetch 
> `foo/.git' which will fail).
> 
>>> know if these issues are only related to dumb protocols (HTTP*) or if
>>> they also affect the Git protocol.  I can't find the relevant thread
>>
>> Hmm... maybe it's http-specific?
>> Things seem to work fine with the git protocol.
> 
> Yeah, that's what I wondered.
> 
>>> on the Git ML but the thing is that it seems that several tools rely
>>> on the fact that a repository name of the form `foo.git' implies that
>>> it's a bare repository (and thus it doesn't need to look for a  nested
>>> .git directory).
>>
>> It has always worked -- on that server, at least.
>> I use that form because I prefer the shorter URL:
>>
>>     git clone git://git.sv.gnu.org/gnulib
>>
>> In general, if you control the server repo,
>> you can simply add a symlink in project.git:
>>
>>     .git -> ..
>>
>> I suppose that avoids any such problems, but I haven't
>> done that on any of the savannah repositories.
> 
> Yeah well that's more of a workaround than anything else.
> 
> My guess: it works with the Git protocol, probably because 
> git-http-fetch works differently than whatever tool does the fetch for 
> the native Git protocol.  OTOH, isn't it better to have a consistent 
> naming?  If you look at the gitweb of gnulib [ 
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git ], it says "URL 
> 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                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231