Re: git doesn't append ".git" to url WAS [PATCH 0/3] http*: refactor fetching code (v2)

Re: git doesn't append ".git" to url WAS [PATCH 0/3] http*: refactor fetching code (v2)

[Tay Ray Chuan]

Hi,

On Wed, May 20, 2009 at 10:03 PM, Tony Finch <dot@dotat.at> wrote:
> On this topic, some of my friends have complained that git doesn't
> automatically try appending .git to a URL when it fails to find a
> bare git repository on the server.

are your friends hosting non-bare repositories directly (with
checked-out copies)? In the first place, this isn't a good idea;
please refer to

 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#def_bare_repository

and

 http://kerneltrap.org/mailarchive/git/2009/1/30/4852194

for reasons why.

-- 
Cheers,
Ray Chuan

Re: git doesn't append ".git" to url WAS [PATCH 0/3] http*: refactor fetching code (v2)

[Tony Finch]

On Thu, 21 May 2009, Tay Ray Chuan wrote:
>
> are your friends hosting non-bare repositories directly (with
> checked-out copies)? In the first place, this isn't a good idea;

Yes, and yes we all know that this is discouraged.

There are two bugs. Git's error message is misleading: the problem is
nothing to do with running git update-server-info (see below). Its
behaviour is inconsistent: git retries after appending .git if you are
fetching from a local repository or ssh:// or git:// URLs but not for
http:// URLs.

$ git clone http://www.greenend.org.uk/rjk/
Initialized empty Git repository in /tmp/rjk/.git/
fatal: http://www.greenend.org.uk/rjk//info/refs not found: did you run git update-server-info on the server?

Actually maybe there's a third bug: it says it has initialized
a repository but it removes it again if the clone fails.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: git doesn't append ".git" to url WAS [PATCH 0/3] http*: refactor fetching code (v2)

[Tay Ray Chuan]

Hi,

On Thu, May 21, 2009 at 10:29 PM, Tony Finch <dot@dotat.at> wrote:
> ...Git's error message is misleading: the problem is
> nothing to do with running git update-server-info (see below).

you're right. Perhaps git should check if the repo (on http://) exists
first, before printing that message.

> Its
> behaviour is inconsistent: git retries after appending .git if you are
> fetching from a local repository or ssh:// or git:// URLs but not for
> http:// URLs.

that's true too.

> Actually maybe there's a third bug: it says it has initialized
> a repository but it removes it again if the clone fails.

well, if the clone fails, then the cloned repo would be in an
incomplete state, so removing it isn't that bad an idea. Perhaps an
option could be made to prevents clone from doing this, so that one
could try restarting the clone.

-- 
Cheers,
Ray Chuan