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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jan 19, 2007, 08:32 UTC
Message-ID: <81b0412b0701190032w686c9403uacd9b3e1e44be307@mail.gmail.com>
In-Reply-To: <45B07C26.4000008@fs.ei.tum.de>

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

Show 9 quoted lines

> >> I guess you are not serious.  I wonder, why does git-ls-files ever
> >> list files under .git?  I'd just say:  fail if you want to list $GIT_DIR.
> >
> > Not list. Clean. What's wrong with listing them?
>
> 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.

Show 12 quoted lines

> >>  Maybe other tools should do so as well.
> >>
> >> % cd .hg && hg status -A .
> >> abort: path contains illegal component: .hg
> >>
> >> I think this is a sensible thing to do.
> >
> > No, it isn't. It is not unlikely to have repo in repo
> > (and some people already have them).
> > Mercurial is wrong here.
>
> what do you mean with repo-in-repo?  something like .git/.git?

Actually, I meant a/b/, with existing a/.git and b/.git, which is obviously is not a case here (nor in mercurial). Stupid me

Show 9 quoted lines

>  My suggestion does not break this:
>
> % mkdir foo && cd foo && git init
> % cd .git && git init
> % git ls-files -o
> HEAD
> config
> description
> hooks/applypatch-msg

I can imagine keeping hooks under git control. In this case path(pwd) does contain .git component (as in .hg example).

> Here the repo root is "foo/.git" and not "foo".
>
> So my suggestion still stands:  .git is off limits.
>

Ok. Have nothing strong against this