Re: Finding the repository

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 23, 2013, 08:49 UTC
Message-ID: <CACsJy8DgxpjasroZv4iqTn9JhQ_3r2DD9uEf-xL-uyyPOtWh+A@mail.gmail.com>
In-Reply-To: <5267804b.JaxQnlQ5Cx+By4RS%perryh@pluto.rain.com>

On Wed, Oct 23, 2013 at 2:52 PM, Perry Hutchison <perryh@pluto.rain.com> wrote:

Show 18 quoted lines

> At least in version 1.7.0.4, it seems git does not like being run
> from outside the repository, even if the file(s) being operated
> on are inside the repository, unless it is given a pointer to the
> repository via the --git-dir= option or the GIT_DIR enironment
> variable.
>
> For example, suppose /foo/bar is a local repository and baz.c is a
> file in the outermost directory that I want to remove.  This works:
>
>   $ cd /foo/bar
>   $ git rm baz.c
>
> but this, which intuitively should mean exactly the same thing,
> fails:
>
>   $ cd /foo
>   $ git rm bar/baz.c
>   fatal: Not a git repository (or any of the parent directories): .git

I share your pain. In my case I hate to go inside a directory just to grep something. In my opinion git should be flexible and work at least in unambiguous cases. But it's not easy to determine ambiguity here, especially when the repo finding code does not know anything about "bar/barz.c" (is it a pathname or an argument to an option?). There are more cases to consider, like what if you do "git rm bar/baz.c and rab/zab.c" where bar and rab are two different repositories.. And the setup code is not exactly easy to add these stuff in..

-- 
Duy