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

David ‘Bombe’ Roden  [off-list ref] 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 ;-)

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