Subject: Re: git status doesn't ignore GIT_DIR directory?

From: Junio C Hamano <[email-masked]>
Date: Sat, 23 May 2015 10:39:39 -0700

Junio C Hamano <[email-masked]> writes:

> Junio C Hamano <[email-masked]> writes:
>
>> I think both of you are wrong ;-)
>>
>> The thing is, what you are seeing does not have much to do with
>> GIT_DIR.  It is "what Git does when it finds a directory inside the
>> working tree of a project".  And ".git" is the only special thing in
>> that context.
>
> In short, I think Duy's "how about this" means well, but adds
> documentation at a wrong place.
>
> Having said all that, the message I am responding to showed the
> right way to look at, understand, and explain the current behaviour.
> It is a separate issue if the current behaviour is optimal from the
> usability point of view.  It is not entirely implausible to extend
> the special casing rules from "a directory named '.git' only" to "in
> addition, the directory pointed at by GIT_DIR, if exists, is treated
> the same way".

If somebody is interested in pursuing this further in the direction
of changing the behaviour (so that Thorsten's original would work as
expected), one thing to be careful about is the case (1) (case (2)
is more or less straight-forward and obvious).

If you do

    $ GIT_DIR=/path/to/worktree/sub/repo.git
    $ GIT_WORK_TREE=/path/to/worktree
    $ export GIT_DIR GIT_WORK_TREE
    $ cd $GIT_WORK_TREE
    $ git add sub

with the current rule, because sub/repo.git does not trigger the
special casing, we may end up adding everything inside our own
repository, which is clearly crazy.  But if you change the rule to
special case the directory pointed at by $GIT_DIR, then we would
start treating that directory as "ah, there is a Git repository".
But the updated code must not say "hence, sub/ is the top level of
the working tree of that repository, so we add it as a submodule".

It instead should just ignore that repo.git directory, just like a
plain vanilla "git add ."  ignores ".git" at the top-level, and add
other things in sub/ directory, i.e. treating sub/ as just a normal
subdirectory in our working tree.

I am not planning to do this in a near future myself, but I thought
I should caution in case anybody is interested.

Thanks.