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

From: Alex Riesen <raa.lkml@gmail.com>
Date: 2007-01-19 20:33:30
On 1/19/07, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> 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

> > 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).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Jan 19 20:34:10 2007

This archive was generated by hypermail 2.1.8 : 2007-01-19 20:35:38 EST