From: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Junio C Hamano <junkio@cox.net>,
Yasushi SHOJI <yashi@atmark-techno.com>,
git@vger.kernel.org
Subject: Re: git ls-files -o under .git/ prints all repository files
Date: Fri, 19 Jan 2007 11:10:46 +0100 [thread overview]
Message-ID: <45B09926.5060306@fs.ei.tum.de> (raw)
In-Reply-To: <81b0412b0701190133o70ab9da3ga0441e9ca16991a9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
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.
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").
To add some facts to it:
GIT-LS-FILES(1) GIT-LS-FILES(1)
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.
>> > 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).
No, the path does *not* contain a .git component. You just committed to the root of the *inside* repo.
Of course I don't say "refuse operation if there is .git in the path". What I mean is, "refuse operation if there is $GIT_DIR in the path". Maybe my example was not complete enough. With mercurial, you can as well have a .hg in .hg.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2007-01-19 10:10 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 [this message]
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
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=45B09926.5060306@fs.ei.tum.de \
--to=corecode@fs.ei.tum.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=raa.lkml@gmail.com \
--cc=yashi@atmark-techno.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.