threads / bug / 14265

[BUG] Git looks for repository in wrong directory

Subject: [BUG] Git looks for repository in wrong directory

## tl;dr

4 messages between Jul 3, 2008 and Jul 3, 2008.

replies: 3people: 2as markdown or json

David ‘Bombe’ Roden· Jul 3, 2008, 00:16 UTC · lore

Hi.

The following sequence:

mkdir r1 cd r1 git init echo a > a git add a git commit -m "a" cd .. git clone r1 r1.git cd r1 echo b > b git add b git commit -m "b" cd .. git ls-remote r1 git ls-remote r1/.

shows that Git searches for a repository in the wrong place. I think the last two commands should output exactly the same but "git ls-remote r1" actually lists the contents of "r1.git". Is that a bug or is this (extremely confusing) behaviour intended?

This also afflicts the behaviour of "git-pull" and friends. I cloned a directory and tried to pull new commits but I repeatedly got stuck with an older commit. I have to move a second directory that was named like the first directory, only with an appended ".git", out of the way so that I could access the repository I asked for.

Used Git version is 1.5.6.1 on Linux 2.6.25.6 (Gentoo/x86).

	David

Junio C Hamano· Jul 3, 2008, 00:31 UTC · re: David ‘Bombe’ Roden · lore

Re: [BUG] Git looks for repository in wrong directory

David ‘Bombe’ Roden  <bombe@pterodactylus.net> writes:

Show 13 quoted lines

> git clone r1 r1.git
> cd r1
> echo b > b
> git add b
> git commit -m "b"
> cd ..
> git ls-remote r1
> git ls-remote r1/.
>
> shows that Git searches for a repository in the wrong place. I think the last 
> two commands should output exactly the same but "git ls-remote r1" actually 
> lists the contents of "r1.git". Is that a bug or is this (extremely 
> confusing) behaviour intended?

This is age old usability feature that lets you say "ls-remote r1" even when you do *not* have "r1.git", and is not limited to the local file transport but also applicable when peeking a remote repository over the native transport.

If you have both, you already have found the way to disambiguate ;-)

David ‘Bombe’ Roden· Jul 3, 2008, 01:05 UTC · re: Junio C Hamano · lore

Re: [BUG] Git looks for repository in wrong directory

On Thursday 03 July 2008 02:31:35 Junio C Hamano wrote:

> This is age old usability feature that lets you say "ls-remote r1" even
> when you do *not* have "r1.git"

Is it just me or does that sentence not make any sense at all? ;)

I mean, _of cource_ I want the contents of "r1" if I say "give me the contents of r1". I could understand if Git looked in "r1.git" if there was no "r1" but the way it is currently done is plain wrong. IMHO, of course.

> If you have both, you already have found the way to disambiguate ;-)

Yes, _now_ I know. In my opinion it’s very unintuitive and should be changed. And if—for some strange reason—this is to be kept as a compatibility feature it should at least be documented somewhere in large red blinking letters that under certain circumstances Git doesn’t care about the path you give it but simply chooses to look somewhere else. :)

	David

Junio C Hamano· Jul 3, 2008, 19:28 UTC · re: David ‘Bombe’ Roden · lore

Re: [BUG] Git looks for repository in wrong directory

David ‘Bombe’ Roden  <bombe@pterodactylus.net> writes:

>> If you have both, you already have found the way to disambiguate ;-)
>
> Yes, _now_ I know. In my opinion it’s very unintuitive and should be changed.

I'm of mixed mind about this.

I am guessing that the original motivation was that people can have unversioned "project/" that perhaps is an extract from the tarball and "project.git/" that is version-controlled by git, and when they want to talk about the repository they can say either "project.git" and "project" to get to the git-managed one, even if "project/" directory exists.

It may be an improvement if we checked to see if the original name does refer to a git repository and use that without falling back. Even though I do not personally care so deeply about this, I won't be opposed to such an improvement.