At Fri, 19 Jan 2007 11:03:17 -0800,
Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > On Fri, 19 Jan 2007, Matthias Kestenholz wrote:
> > ...
> >> Why not check for /.git/ somewhere inside the current working directory
> >> (pwd) ? That's the way mercurial does it currently, and I think that is
> >> a sane thing to do _if_ you want to protect the user from his own
> >> stupidity.
> >
> > There are valid reasons why you might want to have a (possibly
> > temporary) repository _inside_ the GIT_DIR. You'd break these cases.
>
> You are right that strstr(here, "/.git/") is not a good check.
>
> If we really care about this problem (and I am not yet starting
> to think we might, but who knows, I reserve the right to change
> my mind every once in a while), we could make the commands that
> deal with working trees (that is, among the things under
> discussion in this thread, 'git-clean' always is, and
> 'git-ls-files' only when it is given options like '-o', '-k',
> '-m', '-i') when the cwd is GIT_DIR or a subdirectory of it.
I believe it should be done. because it used to be safe during v0.9
time. most command didn't work if you are not in the root dir of a
repo. during the development time, we have been adding feature so that
we don't have to be at a root dir to exec git. we just forgot to
check we are under .git, the repo dir.
I assume that we can either have 1) one more bit in struct
cmd_struct's option field and fail if the command isn't allowed to run
under repository dir, or 2) some mechanism to check prefix, the third
argument of command entry point function, and behave properly.
> If you did something like:
>
> mkdir /var/tmp/a
> cd /var/tmp/a
> git init-db
> cd .git
> GIT_DIR=.git git init-db
> git add .
> git ls-files
> echo junk >garbage
> git clean
>
> the repository at /var/tmp/a/.git/.git ought to track HEAD,
> config and friends in /var/tmp/a/.git directory.
this should always work.
--
yashi
-
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