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

From: Junio C Hamano <[email-masked]>
Date: Mon, 24 Mar 2008 17:32:18 -0700

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

>> 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.