All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Matthias Kestenholz <lists@spinlock.ch>,
	Andreas Ericsson <ae@op5.se>, Alex Riesen <raa.lkml@gmail.com>,
	Simon 'corecode' Schubert <corecode@fs.ei.tum.de>,
	git@vger.kernel.org
Subject: Re: git ls-files -o under .git/ prints all repository files
Date: Tue, 23 Jan 2007 20:12:39 +0900	[thread overview]
Message-ID: <878xfuuhco.wl@mail2.atmark-techno.com> (raw)
In-Reply-To: <7vtzymhma2.fsf@assigned-by-dhcp.cox.net>

At Fri, 19 Jan 2007 11:03:17 -0800,
Junio C Hamano wrote:
> 
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

  reply	other threads:[~2007-01-23 11:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-19  1:04 git ls-files -o under .git/ prints all repository files Yasushi SHOJI
2007-01-19  6:47 ` Junio C Hamano
2007-01-19  7:27   ` Andy Parkins
2007-01-19  8:32     ` Junio C Hamano
2007-01-19  9:04       ` Andy Parkins
2007-01-19  7:41   ` Yasushi SHOJI
2007-01-19  7:51   ` Simon 'corecode' Schubert
2007-01-19  7:57     ` Alex Riesen
2007-01-19  8:07       ` Simon 'corecode' Schubert
2007-01-19  8:32         ` Alex Riesen
2007-01-19  9:04           ` Simon 'corecode' Schubert
2007-01-19  9:33             ` Alex Riesen
2007-01-19 10:10               ` Simon 'corecode' Schubert
2007-01-19 10:38                 ` Alex Riesen
2007-01-19 12:19                   ` Simon 'corecode' Schubert
2007-01-19 13:30       ` Andreas Ericsson
2007-01-19 13:46         ` Matthias Kestenholz
2007-01-19 15:00           ` Johannes Schindelin
2007-01-19 19:03             ` Junio C Hamano
2007-01-23 11:12               ` Yasushi SHOJI [this message]
2007-01-23 12:30                 ` [PATCH] Commands requiring a work tree must not run in GIT_DIR Johannes Schindelin
2007-01-24 11:44                   ` Junio C Hamano
2007-01-24 14:14                     ` Johannes Schindelin
2007-01-24 22:51                       ` Junio C Hamano
2007-01-19  8:02   ` git ls-files -o under .git/ prints all repository files Alex Riesen
2007-01-19  8:01 ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878xfuuhco.wl@mail2.atmark-techno.com \
    --to=yashi@atmark-techno.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ae@op5.se \
    --cc=corecode@fs.ei.tum.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=lists@spinlock.ch \
    --cc=raa.lkml@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.