On 1/19/07, Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> 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
of course git-ls-files will do no harm. but "fixing" every consumer of
git-ls-files seems wrong to me.
There are not that many users of ls-files, which could harm a repo.
Besides of git-clean, cannot think of any.
okay, what do I expect when doing cd .git && git-ls-files?
Either listing *all files* in the repo (like git-ls-files from the
repo root) or no files at all, or failure (".git is private").
List nothing. That's what it does. It could return non-0
(which it does not), but aside from that,... looks very sensible.
NAME
git-ls-files - Information about files in the index/working directory
That's pretty clear to me. Working directory. .git is *not* part of the working directory.
Alright, it is not. I can even imagine someone having a script
containing "git-ls-files -o| rm -f; git reset --hard" to get clean working dir,
and starting the script in .git one day. Make "-o" list nothing as well?
> 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).
No, the path does *not* contain a .git component. You just
committed to the root of the *inside* repo.
"$OLDPWD/.git/hooks". It does contain ".git" :)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html