Re: git ls-files -o under .git/ prints all repository files

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jan 19, 2007, 09:33 UTC
Message-ID: <81b0412b0701190133o70ab9da3ga0441e9ca16991a9@mail.gmail.com>
In-Reply-To: <45B0898B.5040804@fs.ei.tum.de>

On 1/19/07, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:

Show 8 quoted lines

> Alex Riesen wrote:
> >> i would claim .git to be off limits and unrelated to the working dir
> >> (file-wise).  if you want to list files there, do a find . or so.
> >>  After all you wouldn't expect cd /usr && git-ls-files -o work there
> >> unless you have a /.git or /usr/.git, right?
> > Right, just see no practical point changing ls-file for that.
>
> right.  .git should be forbidden in higher layers already.

That's where I disagree. git-clean shouldn't clean it, but git-ls-files will do no harm to the directory

Show 9 quoted lines

> > I can imagine keeping hooks under git control.
> > In this case path(pwd) does contain .git component
> > (as in .hg example).
>
> doesn't work either:
>
> % cd .git/hooks
> % git add *
> fatal: unable to add .git/hooks/applypatch-msg to index

cd .git git init git add . git commit

Works. And the path contains .git component. And git-clean here is ok. The test should check if we are in $GIT_DIR and probably $GIT_DIR/{objects,refs,logs}, not just below .git (with ".git" anywhere in pwd, which the mercurial example seem to suggest).