{"thread":{"id":"10449","subject":"Git public repository naming convention (was: Re: users.txt patch)","startedAt":"2007-10-24T08:41:21Z","lastAt":"2007-10-24T09:03:24Z","messageCount":2,"participants":["Benoit SIGOURE","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"57066","messageId":"FD3A6F4E-1570-4AF0-ADDC-5680B4E83C7D@lrde.epita.fr","threadId":"10449","inReplyTo":"87y7dtt0gk.fsf@rho.meyering.net","subject":"Git public repository naming convention (was: Re: users.txt patch)","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-24T08:41:21Z","receivedAt":"2007-10-24T08:41:21Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"[CC: Git-ML]\n\nOn Oct 24, 2007, at 9:51 AM, Jim Meyering wrote:\n> Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:\n>>> On Oct 24, 2007, at 12:28 AM, Paul Eggert wrote:\n>>>> Index: gnulib.html\n>>>> ===================================================================\n>>>> RCS file: /web/gnulib/gnulib/gnulib.html,v\n>>>> retrieving revision 1.13\n>>>> retrieving revision 1.16\n>>>> diff -p -u -r1.13 -r1.16\n>>>> --- gnulib.html\t22 Oct 2007 21:41:43 -0000\t1.13\n>>>> +++ gnulib.html\t23 Oct 2007 22:22:18 -0000\t1.16\n>>>> @@ -57,14 +57,20 @@ You can also view the <a href=\"MODULES.h\n>>>>  anonymous <a href='http://git.or.cz/'>Git</a>, using the following\n>>>>  shell command:</p>\n>>>>\n>>>> -<pre><samp>git clone git://git.savannah.gnu.org/gnulib.git\n>>>> +<pre><samp>git clone git://git.savannah.gnu.org/gnulib\n>>>>  </samp></pre>\n>>\n>> Is there any reason why this has changed?  I learned (the hard way)\n>> that for bare public repositories, it's better to stick to what turns\n>> out to be more than a naming convention of `project.git'.  I don't\n>\n> What are the consequences of not doing that?\n\nYou can't git-clone the remote repo because it tries to fetch the  \nwrong URL (if the url isn't of the form `foo.git' it will try to  \nfetch `foo/.git' which will fail).\n\n>> know if these issues are only related to dumb protocols (HTTP*) or if\n>> they also affect the Git protocol.  I can't find the relevant thread\n>\n> Hmm... maybe it's http-specific?\n> Things seem to work fine with the git protocol.\n\nYeah, that's what I wondered.\n\n>> on the Git ML but the thing is that it seems that several tools rely\n>> on the fact that a repository name of the form `foo.git' implies that\n>> it's a bare repository (and thus it doesn't need to look for a   \n>> nested\n>> .git directory).\n>\n> It has always worked -- on that server, at least.\n> I use that form because I prefer the shorter URL:\n>\n>     git clone git://git.sv.gnu.org/gnulib\n>\n> In general, if you control the server repo,\n> you can simply add a symlink in project.git:\n>\n>     .git -> ..\n>\n> I suppose that avoids any such problems, but I haven't\n> done that on any of the savannah repositories.\n\nYeah well that's more of a workaround than anything else.\n\nMy guess: it works with the Git protocol, probably because git-http- \nfetch works differently than whatever tool does the fetch for the  \nnative Git protocol.  OTOH, isn't it better to have a consistent  \nnaming?  If you look at the gitweb of gnulib [ http:// \ngit.savannah.gnu.org/gitweb/?p=gnulib.git ], it says \"URL git:// \ngit.sv.gnu.org/gnulib.git\".  Oddly enough, whether you add the `.git'  \nor not doesn't seem to change anything.\n\nThe documentation (Documentation/urls.txt) only shows examples of the  \nform `git://host.xz/path/to/repo.git/'.  So do Documentation/core- \ntutorial.txt, Documentation/git-clone.txt and Documentation/ \nrepository-layout.txt (among others).\n\nMaybe the Git gurus will be able to shed some light on this issue.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"57067","messageId":"471F0A5C.6090705@op5.se","threadId":"10449","inReplyTo":"FD3A6F4E-1570-4AF0-ADDC-5680B4E83C7D@lrde.epita.fr","subject":"Re: Git public repository naming convention","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T09:03:24Z","receivedAt":"2007-10-24T09:03:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Benoit SIGOURE wrote:\n> [CC: Git-ML]\n> \n> On Oct 24, 2007, at 9:51 AM, Jim Meyering wrote:\n>> Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:\n>>>> On Oct 24, 2007, at 12:28 AM, Paul Eggert wrote:\n>>>>> Index: gnulib.html\n>>>>> ===================================================================\n>>>>> RCS file: /web/gnulib/gnulib/gnulib.html,v\n>>>>> retrieving revision 1.13\n>>>>> retrieving revision 1.16\n>>>>> diff -p -u -r1.13 -r1.16\n>>>>> --- gnulib.html    22 Oct 2007 21:41:43 -0000    1.13\n>>>>> +++ gnulib.html    23 Oct 2007 22:22:18 -0000    1.16\n>>>>> @@ -57,14 +57,20 @@ You can also view the <a href=\"MODULES.h\n>>>>>  anonymous <a href='http://git.or.cz/'>Git</a>, using the following\n>>>>>  shell command:</p>\n>>>>>\n>>>>> -<pre><samp>git clone git://git.savannah.gnu.org/gnulib.git\n>>>>> +<pre><samp>git clone git://git.savannah.gnu.org/gnulib\n>>>>>  </samp></pre>\n>>>\n>>> Is there any reason why this has changed?  I learned (the hard way)\n>>> that for bare public repositories, it's better to stick to what turns\n>>> out to be more than a naming convention of `project.git'.  I don't\n>>\n>> What are the consequences of not doing that?\n> \n> You can't git-clone the remote repo because it tries to fetch the wrong \n> URL (if the url isn't of the form `foo.git' it will try to fetch \n> `foo/.git' which will fail).\n> \n>>> know if these issues are only related to dumb protocols (HTTP*) or if\n>>> they also affect the Git protocol.  I can't find the relevant thread\n>>\n>> Hmm... maybe it's http-specific?\n>> Things seem to work fine with the git protocol.\n> \n> Yeah, that's what I wondered.\n> \n>>> on the Git ML but the thing is that it seems that several tools rely\n>>> on the fact that a repository name of the form `foo.git' implies that\n>>> it's a bare repository (and thus it doesn't need to look for a  nested\n>>> .git directory).\n>>\n>> It has always worked -- on that server, at least.\n>> I use that form because I prefer the shorter URL:\n>>\n>>     git clone git://git.sv.gnu.org/gnulib\n>>\n>> In general, if you control the server repo,\n>> you can simply add a symlink in project.git:\n>>\n>>     .git -> ..\n>>\n>> I suppose that avoids any such problems, but I haven't\n>> done that on any of the savannah repositories.\n> \n> Yeah well that's more of a workaround than anything else.\n> \n> My guess: it works with the Git protocol, probably because \n> git-http-fetch works differently than whatever tool does the fetch for \n> the native Git protocol.  OTOH, isn't it better to have a consistent \n> naming?  If you look at the gitweb of gnulib [ \n> http://git.savannah.gnu.org/gitweb/?p=gnulib.git ], it says \"URL \n> git://git.sv.gnu.org/gnulib.git\".  Oddly enough, whether you add the \n> `.git' or not doesn't seem to change anything.\n> \n> The documentation (Documentation/urls.txt) only shows examples of the \n> form `git://host.xz/path/to/repo.git/'.  So do \n> Documentation/core-tutorial.txt, Documentation/git-clone.txt and \n> Documentation/repository-layout.txt (among others).\n> \n> Maybe the Git gurus will be able to shed some light on this issue.\n> \n\nThe dwimmery is handled on the server side and always happens unless\ngit-upload-pack gets the --strict flag. In git-daemon, this option is\ncalled \"--strict-paths\".\n\ngit clone http://anything means the request doesn't end up in the hands\nof git-upload-pack, so the DWIM code in path.c::enter_repo() is never\nrun.\n\nLetting http-fetch re-implement the same dwimmery, using a trial/error\napproach, but saving the correct URL in the remotes config, should\nsolve this problem, although it will be quite slow on high-latency\nnetworks. Perhaps that doesn't matter, as it should only be an issue\nfor the original clone.\n\nThe suffixes to try are these:\nconst char *suffix[] = { \".git/.git\", \"/.git\", \".git\", \"\", NULL };\n\nI believe gitweb mimics this behaviour.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}