Re: git status doesn't ignore GIT_DIR directory?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Hommey <mh@xxxxxxxxxxxx> writes:

> On Sat, May 23, 2015 at 09:22:56AM +0700, Duy Nguyen wrote:
>> On Fri, May 22, 2015 at 07:03:48PM -0700, Junio C Hamano wrote:
>> > As far as I know, GIT_DIR was prepared as a mechanism to point at
>> > another .git directory that does not live inside the working tree, not
>> > as a mechanism to rename it to arbitrary name. E.g.
>> > 
>> >  $ git init
>> >  $ mv .git .svn
>> >  $ GIT_DIR=$(pwd)/.svn ; export GIT_DIR
>> > 
>> > is not expected to work.
>> ...
>> ++
>> +Note that if GIT_DIR is set explicitly to a directory inside working
>> +tree, the directory name must be ".git".
>
> Isn't the requirement that it _ends_ with ".git" (that is,
> GIT_DIR=/path/to/foo.git would work)

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.

When we find a directory whose name is ".git", whether it is the
same as GIT_DIR or not (and "not" case includes when you do not have
GIT_DIR defined), "git add" thinks "Ah, that is a repository proper,
and I wouldn't add it to my project".  It can do two things.  (1) if
it is not at the top of the working tree, i.e. some/directory/.git,
then some/directory is a submodule of the project that has the
working tree we are talking about (unless some/.git exists which
makes some/directory/.git a submodule of the project that has some/
as its working tree, of course), so "git add" would treat
some/directory as a thing to add.  (2) if it is at the top of the
working tree, it does not do anything to it, as it does not make
sense to add the whole working tree as a separate submodule of
ourselves.

The same for "git status".  (1) is treated as a submodule and we do
not consider individual files in some/directory/.git as untracked.
(2) we do not cconsider individual files in .git as untracked.

GIT_DIR further comes into play when it is _not_ defined.  In that
case we try upwards to find a directory that has ".git" subdirectory
and contains our $(cwd), and then declare it as our repository.

And when GIT_DIR points at somewhere that does not affect all of the
above (i.e. trying to see if a random directory inside our working
tree is a ".git" repository), it can be named anything.  If you are
working in /path/to/my/work/tree with GIT_DIR set, it can point at
/path/to/my/repository_git (note that it does not end with ".git",
and note also that it is outside our working tree) just fine.

If you move that directory to /path/to/my/worktree/repository_git,
and point at it with GIT_DIR, we will notice that is our repository
metadata, but "git add" and friends will see "repository_git" is
different from ".git" and the special casing rules for directories
inside working tree do not kick in.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]