From: Alex Riesen Date: Fri, 19 Jan 2007 08:32:02 GMT Subject: Re: git ls-files -o under .git/ prints all repository files Message-ID: <81b0412b0701190032w686c9403uacd9b3e1e44be307@mail.gmail.com> In-Reply-To: <45B07C26.4000008@fs.ei.tum.de> On 1/19/07, Simon 'corecode' Schubert wrote: > >> 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. > >> 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 > 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