[BUG] Git looks for repository in wrong directory

[BUG] Git looks for repository in wrong directory

[David ‘Bombe’ Roden]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Junio C Hamano]

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

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

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

[David ‘Bombe’ Roden]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Junio C Hamano]

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.