Re: Alternates corruption issue

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 31, 2012, 21:55 UTC
Message-ID: <20120131215501.GF13252@burratino>
In-Reply-To: <20120131214740.GA2465@sigill.intra.peff.net>

Jeff King wrote:

Show 15 quoted lines

> Right. But would you expect:
>
>   git ls-remote foo
>
> to behave the same as:
>
>   cd foo
>   git ls-remote .
>
> and would you furthermore expect that to behave the same as:
>
>   cd foo
>   git rev-parse --git-dir
>
> ?

Nah.  I never run "git ls-remote .". ;-)

[...]

>>  2) As a naive user, I would expect (A) to give a different result
>>     from (B).
>
> Why?

Normally git commands expect me to be in (possibly a deeply nested subdirectory) of the worktree. The typical case is a non-bare repository. I have been taught that it walks to the toplevel and finds a ".git" directory.

By contrast, the path passed to git transport commands like "git fetch otherhost:/foo/bar/baz.git" is a path to the git repository metadata. I am not allowed to pass a path to a subdirectory, for example.

As a user, when would the distinction ever come up? One is a fuzzy "which repository am I working in", and the other is a precise "point me to the metadata directory, but I allow you to abbreviate a little by leaving out the trailing .git".