git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mike Hommey <mh@glandium.org>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Thorsten von Eicken <tve@rightscale.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: git status doesn't ignore GIT_DIR directory?
Date: Sat, 23 May 2015 09:54:05 -0700	[thread overview]
Message-ID: <xmqq1ti7dyky.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150523053900.GA2364@glandium.org> (Mike Hommey's message of "Sat, 23 May 2015 14:39:00 +0900")

Mike Hommey <mh@glandium.org> 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.

  parent reply	other threads:[~2015-05-23 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-23  1:03 git status doesn't ignore GIT_DIR directory? Thorsten von Eicken
2015-05-23  2:03 ` Junio C Hamano
2015-05-23  2:22   ` Duy Nguyen
2015-05-23  4:41     ` Thorsten von Eicken
2015-05-23 11:53       ` Duy Nguyen
2015-05-23  5:39     ` Mike Hommey
2015-05-23 11:42       ` Duy Nguyen
2015-05-23 16:54       ` Junio C Hamano [this message]
2015-05-23 17:00         ` Junio C Hamano
2015-05-23 17:39           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq1ti7dyky.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=pclouds@gmail.com \
    --cc=tve@rightscale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).