Re: [bug] git-add won't add foo/.git/bar

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2008, 00:32 UTC
Message-ID: <7vve3br6ct.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7v1w5zslv5.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 5 quoted lines

>> Well, git won't allow .git as a element anywhere in the path, when we
>> should only care about the _first_ one - and also, if you use
>> --git-dir=banana then we still check for '.git' ... oops.
>
> That's not how git-dir is supposed to used, so there is no oops.

The only purpose of git-dir is to have $GIT_DIR elsewhere _outside_ the work tree.

That is, not "git --git-dir=banana", but "git --git-dir=$(pwd)/../banana" or more typically "git --git-dir=/home/gits/banana.git/" when you are at the toplevel of your work tree that is unrelated to the named location.

> Also it is false that we should only care about the first one.  Think
> submodules.

Actually, not just "submodules", but even with more traditional "overlayed checkout" with working in a subdirectory, you would have problems.

You can have another repository in your work tree, and the way we tell which path belongs to which repository is by finding .git directory in the hierarchy. In my work trees of git.git, I have a clone of the repository itself in Meta/ and have checkout of 'todo' branch, like this:

	/git.git/.git
        	/COPYING
                /Documentation
                /Makefile
                /Meta/.git
                /Meta/Doit
                /Meta/MaintNotes
                /Meta/Make
                ...

In such a layout, you can

	$ cd Meta
        $ edit MaintNotes
        $ git commit

and commit the result to the /git.git/Meta/.git/ repository, while you can

	$ cd Documentation
        $ edit git.txt
        $ git commit

and the result is committed to the main /git.git/.git/ repository.

What this means is that you cannot have .git/ directory anywhere in your work tree unless the directory that house such a .git directory as its direct subdirectory (e.g. /git.git/Meta in the above illustration) unless that hierarchy does not belong to the main repository (e.g. /git.git/).

Having, say Documentation/.git, in the above example is wrong because you want the file Documentation/git.txt to be part of the main project.

And trying to add Documentation/.git/garbage is doubly wrong. For one thing, that path is a place to hold metainformation of the /git.git/Documentation/.git repository (i.e. not something you can "git add" to the /git.git/Documentation/.git repository), and because it is part of /git.git/Documentation/.git repository, it should not even go to the main project (i.e. not something you can "git add" to the main /git.git/.git repository either).

A few weeks ago somebody wanted to rename .git and I thought I responded well enough. You certainly did not ask CVS or SVN folks to rename the control directories they sprinkle in your work trees to .cvs or .svn, did you? Leave .git alone so that people don't get confused.