Git public repository naming convention

DISCUSSION Andreas Ericsson 2 participants 2 messages Jun 15, 2016 7 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Benoit SIGOURE

2016-06-15 22:43 UTC #7 lore raw

Git public repository naming convention (was: Re: users.txt patch)

[CC: Git-ML]

Quoted 22 lines · Jim Meyering

Quoted 13 lines · Benoit SIGOURE
Quoted 13 lines · Paul Eggert
Quoted 12 lines
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 +0 -0
@@ -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>
 
Quoted 7 lines
Quoted 3 lines
gnulib.html You can also view the <a href="MODULES.h · line 61
Quoted 3 lines
gnulib.html +1 -1
-<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

Quoted 1 line

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).

Quoted 5 lines

Quoted 2 lines
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.

Quoted 10 lines

Quoted 4 lines
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

Quoted 7 lines

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.

Cheers,

Signature · 2 lines

Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Andreas Ericsson

author

2016-06-15 22:43 UTC #8 lore raw

Quoted 55 lines · Benoit SIGOURE

[CC: Git-ML]
Quoted 22 lines · Jim Meyering
Quoted 13 lines · Benoit SIGOURE
Quoted 13 lines · Paul Eggert
Quoted 12 lines
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 23 Oct 2007 22:22:18 -0000 1.16 renamed from gnulib.html 22 Oct 2007 21:41:43 -0000 1.13 +0 -0
@@ -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>
 
Quoted 7 lines
Quoted 3 lines
gnulib.html 23 Oct 2007 22:22:18 -0000 1.16 You can also view the <a href="MODULES.h · line 61
Quoted 3 lines
gnulib.html 23 Oct 2007 22:22:18 -0000 1.16 renamed from gnulib.html 22 Oct 2007 21:41:43 -0000 1.13 +1 -1
-<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
Quoted 1 line
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).
Quoted 5 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 4 lines
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
Quoted 7 lines
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.

Quoted 8 lines

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.

Signature · 3 lines

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231