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

hi,

% git-add -f foo/.git/bar fatal: unable to add foo/.git/bar to index

How do i add such a file to a git repository?

thx && cu, michael

On Tue, 25 Mar 2008, Michael Gebetsroither wrote:

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.

patch in the works ... ;)

wait? :P

Sorry, can't see any easy way to work around this atm.

Julian Phillips <julian@quantumfyre.co.uk> writes:

That's not how git-dir is supposed to used, so there is no oops.

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

On Mon, 24 Mar 2008, Junio C Hamano wrote:

So I can't _ever_ have a directory/file called '.git'? But I _can_ add files inside my repository provided that the repository is not called .git? How is that not an oops, or extremely confusing at the least?

i.e.:

'git add .git/fred' fails 'git --git-dir=.git_repos --work-tree=. add .git/fred' fails 'git --git-dir=.git_repos --work-tree=. add .git_repos/fred' works

Ok, true. I've never used submodules, can you add things inside submodules from the parent? If so, where do they get added - presumably to the submodule?

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

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.

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.

On Mon, 24 Mar 2008, Junio C Hamano wrote:

That's fair enough. It's not enforced, or discourgaed in the documentation though. Would a patch to mention that using --git-dir/GIT_DIR to change the name _inside_ the work tree is not supported be accepted?

Well, no - but then I hold git to a higher standard. ;)

Agreed, it is a) a lot simpler to explain, b) less likely to break things. Sorry for wasting your time :$, an interesting poke around the code though. :)

Something I noticed that seemed a bit odd when playing with this, should I expect git to stop me from trying to add files inside subprojects to the main project? It seems to just discard the submodule and turn it into a normal directory when I do. Is that intended behaviour?

We don't support using --git-dir/GIT_DIR to change the name of the .git directory, so make this clear in the documentation.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
On Tue, 25 Mar 2008, Julian Phillips wrote:

we

i.e. this ...

 Documentation/git.txt |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

* Junio C Hamano <gitster@pobox.com> wrote:

Would it be possible to allow it with git-add -f or does that break to many cases?

cu, michael

On Tue, 25 Mar 2008, Michael Gebetsroither wrote:

It would be possible, but Junio has convinced me that it wouldn't really be wise. Inside the working tree .git is a special name - end of story.

It would be relatively easy to change the check that prevents you from doing it - but this wouldn't stop any of the nasty things that could ensue. You might never have a problem with a simple layout, but it could cause mayhem for others with more complicated layouts.

(I've never used any of the more complicated layouts either, which is why I didn't initially see the problems ... ho hum)

* Julian Phillips <julian@quantumfyre.co.uk> wrote:

fair enough, thx :)

cu, michael