On 1/19/07, Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> 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 - 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