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.htmlReceived on Fri Jan 19 20:34:10 2007
This archive was generated by hypermail 2.1.8 : 2007-01-19 20:35:38 EST