{"thread":{"id":"6433","subject":"git ls-files -o under .git/ prints all repository files","startedAt":"2007-01-19T01:04:12Z","lastAt":"2007-01-24T22:51:38Z","messageCount":26,"participants":["Yasushi SHOJI","Junio C Hamano","Andy Parkins","Simon 'corecode' Schubert","Alex Riesen","Andreas Ericsson","Matthias Kestenholz","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32029","messageId":"87r6trsu7n.wl@mail2.atmark-techno.com","threadId":"6433","inReplyTo":null,"subject":"git ls-files -o under .git/ prints all repository files","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2007-01-19T01:04:12Z","receivedAt":"2007-01-19T01:04:12Z","isPatch":false,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"Hi all,\n\nls-files -o prints all files under .git if you are in the .git\ndirectory. this is pretty dangerous since we now have git clean to\ndelete files marked others.\n\nsure in UNIX env., you can easily shoot yourself in the foot. but it'd\nmight be nice to help newbies.\n\nI'm not sure how we should fix this. should we\n\n1) prevent to run any git command under .git unless .git is also\n managed by git (ie. .git/.git or something exists)\n\n2) prevent ls-files -o to print any files under .git/ even if we are\n in the directory.\n\n\nthe way to reproduce is:\n\n\n$ git init\nInitialized empty Git repository in .git/\n$ echo hello > hello.c\n$ git add .\n$ git commit -m initial\nCreated initial commit b40c824b521f6c60434043f0cce08a88b4031ed8\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 hello.c\n$ cd .git\n$ git ls-files -o\nHEAD\nconfig\ndescription\nhooks/applypatch-msg\nhooks/commit-msg\nhooks/post-commit\nhooks/post-update\nhooks/pre-applypatch\nhooks/pre-commit\nhooks/pre-rebase\nhooks/update\nindex\ninfo/exclude\nlogs/refs/heads/master\nobjects/b4/0c824b521f6c60434043f0cce08a88b4031ed8\nobjects/bc/2d2dcb34e8313627d45ad6ef38beddf560501d\nobjects/ce/013625030ba8dba906f756967f9e9ca394464a\nrefs/heads/master\n$ git clean\nRemoving HEAD\nNot removing branches/\nRemoving config\nRemoving description\nNot removing hooks/\nRemoving index\nNot removing info/\nNot removing logs/\nNot removing objects/\nNot removing refs/\nNot removing remotes/\n$ cd ..\n$ git ls-files\nfatal: Not a git repository\n$ \n-- \n yashi\n"},{"id":"32035","messageId":"7vwt3jjywc.fsf@assigned-by-dhcp.cox.net","threadId":"6433","inReplyTo":"87r6trsu7n.wl@mail2.atmark-techno.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-19T06:47:47Z","receivedAt":"2007-01-19T06:47:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yasushi SHOJI writes:\n\n> ls-files -o prints all files under .git if you are in the .git\n> directory. this is pretty dangerous since we now have git clean to\n> delete files marked others.\n>\n> sure in UNIX env., you can easily shoot yourself in the foot. but it'd\n> might be nice to help newbies.\n\nIt's amusing to see that people can find obscure ways to shoot\nthemselves in the foot.\n\nAmusing problems deserve an equally amusing solution.\n\n-- >8 --\n[PATCH] Make sure .git/ is not readable by anybody.\n\nNormal git operation continues to work after doing \"chmod a-r .git\".\nThis makes a newly created git repository unreadable (but searchable)\nso that people cannot do \"cd .git && git clean\" to shoot themselves.\n\nSigned-off-by: Junio C Hamano \n\n---\ndiff --git a/builtin-init-db.c b/builtin-init-db.c\nindex 8e7540b..4310a05 100644\n--- a/builtin-init-db.c\n+++ b/builtin-init-db.c\n@@ -18,7 +18,10 @@\n \n static void safe_create_dir(const char *dir, int share)\n {\n-\tif (mkdir(dir, 0777) < 0) {\n+\tmode_t mode;\n+\n+\tmode = share ? 0777 : 0333;\n+\tif (mkdir(dir, mode) < 0) {\n \t\tif (errno != EEXIST) {\n \t\t\tperror(dir);\n \t\t\texit(1);\n"},{"id":"32037","messageId":"200701190727.26505.andyparkins@gmail.com","threadId":"6433","inReplyTo":"7vwt3jjywc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-19T07:27:24Z","receivedAt":"2007-01-19T07:27:24Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, January 19 06:47, Junio C Hamano wrote:\n\n> +\tmode = share ? 0777 : 0333;\n\nSo if the repository is shared we're allowed to shoot ourselves in the foot?\n\nAlso; what does this do to .git/config .git/description?\n\nOn ocassion I've found myself doing\n mv .git/refs/remotes/origin .git/refs/remotes/up\n\nWhich this patch would break. (Maybe I shouldn't be doing that though, so \nperhaps it should break :-))\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"32038","messageId":"87k5zjsbsr.wl@mail2.atmark-techno.com","threadId":"6433","inReplyTo":"7vwt3jjywc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2007-01-19T07:41:56Z","receivedAt":"2007-01-19T07:41:56Z","isPatch":false,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Thu, 18 Jan 2007 22:47:47 -0800,\nJunio C Hamano wrote:\n> \n> Yasushi SHOJI writes:\n> \n> > ls-files -o prints all files under .git if you are in the .git\n> > directory. this is pretty dangerous since we now have git clean to\n> > delete files marked others.\n> >\n> > sure in UNIX env., you can easily shoot yourself in the foot. but it'd\n> > might be nice to help newbies.\n> \n> It's amusing to see that people can find obscure ways to shoot\n> themselves in the foot.\n> \n> Amusing problems deserve an equally amusing solution.\n\nUnfortunately, the amusing ;-) solution doesn't prevent them all.\n\n$ cd .git/objects\n$ git ls-fiels -o\n0f/902e4635d4d7b8e532b485eeeb6399d0910710\nbc/2d2dcb34e8313627d45ad6ef38beddf560501d\nce/013625030ba8dba906f756967f9e9ca394464a\n$ git clean -d -x\nRemoving 0f/\nRemoving bc/\nRemoving ce/\nRemoving info/\nRemoving pack/\n\nI presume that if the cwd is the direct decedent of the current\nGIT_DIR, ls-files should print error saying \"you are not in the\nworking dir\".\n\nor, just ignore '.git/*' all the time.\n\n$ git ls-files -o\nHEAD\nconfig\n :\n$ git ls-files -o --exclude='.git/*'\n$ \n\nWhat do you think?\n-- \n yashi\n"},{"id":"32039","messageId":"45B07875.9030506@fs.ei.tum.de","threadId":"6433","inReplyTo":"7vwt3jjywc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-19T07:51:17Z","receivedAt":"2007-01-19T07:51:17Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Yasushi SHOJI writes:\n> \n>> ls-files -o prints all files under .git if you are in the .git\n>> directory. this is pretty dangerous since we now have git clean to\n>> delete files marked others.\n>>\n>> sure in UNIX env., you can easily shoot yourself in the foot. but it'd\n>> might be nice to help newbies.\n> \n> It's amusing to see that people can find obscure ways to shoot\n> themselves in the foot.\n> \n> Amusing problems deserve an equally amusing solution.\n\nI 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. Maybe other tools should do so as well.\n\n% cd .hg && hg status -A .\nabort: path contains illegal component: .hg\n\nI think this is a sensible thing to do.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32040","messageId":"81b0412b0701182357l3a6d44fel58da50c7895fb6b4@mail.gmail.com","threadId":"6433","inReplyTo":"45B07875.9030506@fs.ei.tum.de","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T07:57:58Z","receivedAt":"2007-01-19T07:57:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Simon 'corecode' Schubert wrote:\n> >\n> > Amusing problems deserve an equally amusing solution.\n>\n> I guess you are not serious. I wonder, why does git-ls-files ever\n> list files under .git? I'd just say: fail if you want to list $GIT_DIR.\n\nNot list. Clean. What's wrong with listing them?\n\n> Maybe other tools should do so as well.\n>\n> % cd .hg && hg status -A .\n> abort: path contains illegal component: .hg\n>\n> I think this is a sensible thing to do.\n\nNo, it isn't. It is not unlikely to have repo in repo\n(and some people already have them).\nMercurial is wrong here.\n"},{"id":"32041","messageId":"81b0412b0701190001n10b84df8icb98ee65c05351e8@mail.gmail.com","threadId":"6433","inReplyTo":"87r6trsu7n.wl@mail2.atmark-techno.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T08:01:47Z","receivedAt":"2007-01-19T08:01:47Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Yasushi SHOJI wrote:\n> sure in UNIX env., you can easily shoot yourself in the foot. but it'd\n> might be nice to help newbies.\n\nIt's is not just Unix. Humans are known for shooting themselves\nin feet, heads and other parts of their bodies. It's a popular way\nof taking life in own hands.\n\nSeriously, though, git-clean can just refuse cleaning $GIT_DIR.\n"},{"id":"32042","messageId":"81b0412b0701190002i1552a16bq5ba7cbebcaa729df@mail.gmail.com","threadId":"6433","inReplyTo":"7vwt3jjywc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T08:02:50Z","receivedAt":"2007-01-19T08:02:50Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Junio C Hamano wrote:\n> static void safe_create_dir(const char *dir, int share)\n> {\n> - if (mkdir(dir, 0777) < 0) {\n> + mode_t mode;\n> +\n> + mode = share ? 0777 : 0333;\n> + if (mkdir(dir, mode) < 0) {\n\nDoes not work for existing directories, does not work\non FAT and alike at all.\n"},{"id":"32043","messageId":"45B07C26.4000008@fs.ei.tum.de","threadId":"6433","inReplyTo":"81b0412b0701182357l3a6d44fel58da50c7895fb6b4@mail.gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-19T08:07:02Z","receivedAt":"2007-01-19T08:07:02Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> I guess you are not serious. I wonder, why does git-ls-files ever\n>> list files under .git? I'd just say: fail if you want to list $GIT_DIR.\n> \n> Not list. Clean. What's wrong with listing them?\n\ni 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?\n\n>> Maybe other tools should do so as well.\n>>\n>> % cd .hg && hg status -A .\n>> abort: path contains illegal component: .hg\n>>\n>> I think this is a sensible thing to do.\n> \n> No, it isn't. It is not unlikely to have repo in repo\n> (and some people already have them).\n> Mercurial is wrong here.\n\nwhat do you mean with repo-in-repo? something like .git/.git? My suggestion does not break this:\n\n% mkdir foo && cd foo && git init\n% cd .git && git init\n% git ls-files -o\nHEAD\nconfig\ndescription\nhooks/applypatch-msg\nhooks/commit-msg\nhooks/post-commit\nhooks/post-update\nhooks/pre-applypatch\nhooks/pre-commit\nhooks/pre-rebase\nhooks/update\ninfo/exclude\n% git ls-files -o ..\nfatal: '..' is outside repository\n\nHere the repo root is \"foo/.git\" and not \"foo\".\n\nSo my suggestion still stands: .git is off limits.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32044","messageId":"81b0412b0701190032w686c9403uacd9b3e1e44be307@mail.gmail.com","threadId":"6433","inReplyTo":"45B07C26.4000008@fs.ei.tum.de","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T08:32:02Z","receivedAt":"2007-01-19T08:32:02Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Simon 'corecode' Schubert wrote:\n> >> I guess you are not serious. I wonder, why does git-ls-files ever\n> >> list files under .git? I'd just say: fail if you want to list $GIT_DIR.\n> >\n> > Not list. Clean. What's wrong with listing them?\n>\n> i would claim .git to be off limits and unrelated to the working dir\n> (file-wise). if you want to list files there, do a find . or so.\n> After all you wouldn't expect cd /usr && git-ls-files -o work there\n> unless you have a /.git or /usr/.git, right?\n\nRight, just see no practical point changing ls-file for that.\n\n> >> Maybe other tools should do so as well.\n> >>\n> >> % cd .hg && hg status -A .\n> >> abort: path contains illegal component: .hg\n> >>\n> >> I think this is a sensible thing to do.\n> >\n> > No, it isn't. It is not unlikely to have repo in repo\n> > (and some people already have them).\n> > Mercurial is wrong here.\n>\n> what do you mean with repo-in-repo? something like .git/.git?\n\nActually, I meant a/b/, with existing a/.git and b/.git, which is\nobviously is not a case here (nor in mercurial). Stupid me\n\n> My suggestion does not break this:\n>\n> % mkdir foo && cd foo && git init\n> % cd .git && git init\n> % git ls-files -o\n> HEAD\n> config\n> description\n> hooks/applypatch-msg\n\nI can imagine keeping hooks under git control.\nIn this case path(pwd) does contain .git component\n(as in .hg example).\n\n> Here the repo root is \"foo/.git\" and not \"foo\".\n>\n> So my suggestion still stands: .git is off limits.\n>\n\nOk. Have nothing strong against this\n"},{"id":"32045","messageId":"7vfya7ju1l.fsf@assigned-by-dhcp.cox.net","threadId":"6433","inReplyTo":"200701190727.26505.andyparkins@gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-19T08:32:38Z","receivedAt":"2007-01-19T08:32:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Friday 2007, January 19 06:47, Junio C Hamano wrote:\n>\n>> +\tmode = share ? 0777 : 0333;\n>\n> So if the repository is shared we're allowed to shoot ourselves in the foot?\n\nHave you actually read the code to see what 'share' variable\nmeans there? It is only false when creating the toplevel .git\ndirectory and always true for its subdirectories.\n\n> Also; what does this do to .git/config .git/description?\n\nNothing unusual. The code explicitly asks for .git/config by\nname, so that does not involve readdir(\".git\"), which is what\nthe 0333 change prevents from running.\n\n> On ocassion I've found myself doing\n> mv .git/refs/remotes/origin .git/refs/remotes/up\n>\n> Which this patch would break.\n\nDoes it?\n\nAnd everybody commented on this thread,\n\n\tEASY.\n\nYou all should not take \"amusing\" too seriously. That was a\ntongue-in-cheek patch.\n\nI am very inclined to say\n\n\t$ cd .git && git clean\n\nor\n\n\t$ cd .git/objects && git clean \n\nfalls into the same category as\n\n\t$ su\n\t# cd / && git-init-db && git clean\n\nIn other words, I am not sure if there is anything worth fixing.\n"},{"id":"32046","messageId":"45B0898B.5040804@fs.ei.tum.de","threadId":"6433","inReplyTo":"81b0412b0701190032w686c9403uacd9b3e1e44be307@mail.gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-19T09:04:11Z","receivedAt":"2007-01-19T09:04:11Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> i would claim .git to be off limits and unrelated to the working dir\n>> (file-wise). if you want to list files there, do a find . or so.\n>> After all you wouldn't expect cd /usr && git-ls-files -o work there\n>> unless you have a /.git or /usr/.git, right?\n> Right, just see no practical point changing ls-file for that.\n\nright. .git should be forbidden in higher layers already.\n\n> I can imagine keeping hooks under git control.\n> In this case path(pwd) does contain .git component\n> (as in .hg example).\n\ndoesn't work either:\n\n% cd .git/hooks\n% git add *\nfatal: unable to add .git/hooks/applypatch-msg to index\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32047","messageId":"200701190904.58515.andyparkins@gmail.com","threadId":"6433","inReplyTo":"7vfya7ju1l.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-19T09:04:53Z","receivedAt":"2007-01-19T09:04:53Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, January 19 08:32, Junio C Hamano wrote:\n\n> Have you actually read the code to see what 'share' variable\n> means there? It is only false when creating the toplevel .git\n\nNope. I'm an idiot :-) I assumed it was from the --shared command line \nargument. What they say about assumptions is true isn't it?\n\n> Nothing unusual. The code explicitly asks for .git/config by\n> name, so that does not involve readdir(\".git\"), which is what\n> the 0333 change prevents from running.\n\nIn this case I was talking more about the user editing those files than the \ncode looking for them. I suppose if you know its there then a \nvim .git/config will be fine.\n\n> > On ocassion I've found myself doing\n> > mv .git/refs/remotes/origin .git/refs/remotes/up\n> >\n> > Which this patch would break.\n>\n> Does it?\n\nYou're right it doesn't. As long as you know the refs directory is there it \ndoesn't stop you changing into it, and messing about in any way you want. I \nwas looking at it from the point of view of how I originally found out about \nthese git inner workings - I did it by poking around in the .git directory.\n\n> You all should not take \"amusing\" too seriously. That was a\n> tongue-in-cheek patch.\n\nFair enough. I took it more as meaning, \"this would fix this problem /and/ \nit's funny too\". Apologies.\n\n> In other words, I am not sure if there is anything worth fixing.\n\nAfter a bit of thought; I think I agree.\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"32048","messageId":"81b0412b0701190133o70ab9da3ga0441e9ca16991a9@mail.gmail.com","threadId":"6433","inReplyTo":"45B0898B.5040804@fs.ei.tum.de","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T09:33:30Z","receivedAt":"2007-01-19T09:33:30Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Simon 'corecode' Schubert wrote:\n> Alex Riesen wrote:\n> >> i would claim .git to be off limits and unrelated to the working dir\n> >> (file-wise). if you want to list files there, do a find . or so.\n> >> After all you wouldn't expect cd /usr && git-ls-files -o work there\n> >> unless you have a /.git or /usr/.git, right?\n> > Right, just see no practical point changing ls-file for that.\n>\n> right. .git should be forbidden in higher layers already.\n\nThat's where I disagree. git-clean shouldn't clean it, but\ngit-ls-files will do no harm to the directory\n\n> > I can imagine keeping hooks under git control.\n> > In this case path(pwd) does contain .git component\n> > (as in .hg example).\n>\n> doesn't work either:\n>\n> % cd .git/hooks\n> % git add *\n> fatal: unable to add .git/hooks/applypatch-msg to index\n\ncd .git\ngit init\ngit add .\ngit commit\n\nWorks. And the path contains .git component. And git-clean\nhere is ok. The test should check if we are in $GIT_DIR\nand probably $GIT_DIR/{objects,refs,logs}, not just below\n.git (with \".git\" anywhere in pwd, which the mercurial\nexample seem to suggest).\n"},{"id":"32053","messageId":"45B09926.5060306@fs.ei.tum.de","threadId":"6433","inReplyTo":"81b0412b0701190133o70ab9da3ga0441e9ca16991a9@mail.gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-19T10:10:46Z","receivedAt":"2007-01-19T10:10:46Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> >> i would claim .git to be off limits and unrelated to the working dir\n>> >> (file-wise). if you want to list files there, do a find . or so.\n>> >> After all you wouldn't expect cd /usr && git-ls-files -o work there\n>> >> unless you have a /.git or /usr/.git, right?\n>> > Right, just see no practical point changing ls-file for that.\n>> right. .git should be forbidden in higher layers already.\n> \n> That's where I disagree. git-clean shouldn't clean it, but\n> git-ls-files will do no harm to the directory\n\nof course git-ls-files will do no harm. but \"fixing\" every consumer of git-ls-files seems wrong to me.\n\nokay, 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\").\n\nTo add some facts to it:\n\nGIT-LS-FILES(1) GIT-LS-FILES(1)\n\nNAME\n git-ls-files - Information about files in the index/working directory\n\nThat's pretty clear to me. Working directory. .git is *not* part of the working directory.\n\n\n>> > I can imagine keeping hooks under git control.\n>> > In this case path(pwd) does contain .git component\n>> > (as in .hg example).\n>>\n>> doesn't work either:\n>>\n>> % cd .git/hooks\n>> % git add *\n>> fatal: unable to add .git/hooks/applypatch-msg to index\n> \n> cd .git\n> git init\n> git add .\n> git commit\n> \n> Works. And the path contains .git component. And git-clean\n> here is ok. The test should check if we are in $GIT_DIR\n> and probably $GIT_DIR/{objects,refs,logs}, not just below\n> .git (with \".git\" anywhere in pwd, which the mercurial\n> example seem to suggest).\n\nNo, the path does *not* contain a .git component. You just committed to the root of the *inside* repo.\n\nOf 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.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32062","messageId":"81b0412b0701190238o79ce8473t2faf1a797565bc5d@mail.gmail.com","threadId":"6433","inReplyTo":"45B09926.5060306@fs.ei.tum.de","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-19T10:38:04Z","receivedAt":"2007-01-19T10:38:04Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/07, Simon 'corecode' Schubert wrote:\n> Alex Riesen wrote:\n> >> >> i would claim .git to be off limits and unrelated to the working dir\n> >> >> (file-wise). if you want to list files there, do a find . or so.\n> >> >> After all you wouldn't expect cd /usr && git-ls-files -o work there\n> >> >> unless you have a /.git or /usr/.git, right?\n> >> > Right, just see no practical point changing ls-file for that.\n> >> right. .git should be forbidden in higher layers already.\n> >\n> > That's where I disagree. git-clean shouldn't clean it, but\n> > git-ls-files will do no harm to the directory\n>\n> of course git-ls-files will do no harm. but \"fixing\" every consumer of\n> git-ls-files seems wrong to me.\n\nThere are not that many users of ls-files, which could harm a repo.\nBesides of git-clean, cannot think of any.\n\n> okay, what do I expect when doing cd .git && git-ls-files?\n> Either listing *all files* in the repo (like git-ls-files from the\n> repo root) or no files at all, or failure (\".git is private\").\n\nList nothing. That's what it does. It could return non-0\n(which it does not), but aside from that,... looks very sensible.\n\n> NAME\n> git-ls-files - Information about files in the index/working directory\n>\n> That's pretty clear to me. Working directory. .git is *not* part of the working directory.\n>\n\nAlright, it is not. I can even imagine someone having a script\ncontaining \"git-ls-files -o| rm -f; git reset --hard\" to get clean working dir,\nand starting the script in .git one day. Make \"-o\" list nothing as well?\n\n> > Works. And the path contains .git component. And git-clean\n> > here is ok. The test should check if we are in $GIT_DIR\n> > and probably $GIT_DIR/{objects,refs,logs}, not just below\n> > .git (with \".git\" anywhere in pwd, which the mercurial\n> > example seem to suggest).\n>\n> No, the path does *not* contain a .git component. You just\n> committed to the root of the *inside* repo.\n\n\"$OLDPWD/.git/hooks\". It does contain \".git\" :)\n"},{"id":"32057","messageId":"45B0B763.2020007@fs.ei.tum.de","threadId":"6433","inReplyTo":"81b0412b0701190238o79ce8473t2faf1a797565bc5d@mail.gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-19T12:19:47Z","receivedAt":"2007-01-19T12:19:47Z","isPatch":false,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Alex Riesen wrote:\n>> okay, what do I expect when doing cd .git && git-ls-files?\n>> Either listing *all files* in the repo (like git-ls-files from the\n>> repo root) or no files at all, or failure (\".git is private\").\n> \n> List nothing. That's what it does. It could return non-0\n> (which it does not), but aside from that,... looks very sensible.\n\nyah, to fail or not to fail. I'd still say listing in .git is invalid, hence fail.\n\n> Alright, it is not. I can even imagine someone having a script\n> containing \"git-ls-files -o| rm -f; git reset --hard\" to get clean \n> working dir,\n> and starting the script in .git one day. Make \"-o\" list nothing as well?\n\nyes, I actually wanted to talk about -o, but forgot to mention. Following my reasoning above, it should fail as well.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32064","messageId":"45B0C7E6.4020509@op5.se","threadId":"6433","inReplyTo":"81b0412b0701182357l3a6d44fel58da50c7895fb6b4@mail.gmail.com","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-19T13:30:14Z","receivedAt":"2007-01-19T13:30:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> On 1/19/07, Simon 'corecode' Schubert wrote:\n>> >\n>>\n>> % cd .hg && hg status -A .\n>> abort: path contains illegal component: .hg\n>>\n>> I think this is a sensible thing to do.\n> \n> No, it isn't. It is not unlikely to have repo in repo\n> (and some people already have them).\n> Mercurial is wrong here.\n\nFor managing repos inside repos (onion repos?) I think it should\nbe safe to abort if we're not at top-level.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"32065","messageId":"1169214414.18684.25.camel@localhost.localdomain","threadId":"6433","inReplyTo":"45B0C7E6.4020509@op5.se","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Matthias Kestenholz","fromEmail":"lists@spinlock.ch","sentAt":"2007-01-19T13:46:54Z","receivedAt":"2007-01-19T13:46:54Z","isPatch":false,"sender":{"key":"lists@spinlock.ch","avatar":null},"body":"On Fri, 2007-01-19 at 14:30 +0100, Andreas Ericsson wrote:\n> Alex Riesen wrote:\n> > On 1/19/07, Simon 'corecode' Schubert wrote:\n> >> >\n> >>\n> >> % cd .hg && hg status -A .\n> >> abort: path contains illegal component: .hg\n> >>\n> >> I think this is a sensible thing to do.\n> > \n> > No, it isn't. It is not unlikely to have repo in repo\n> > (and some people already have them).\n> > Mercurial is wrong here.\n> \n> For managing repos inside repos (onion repos?) I think it should\n> be safe to abort if we're not at top-level.\n> \n\n\nWhy not check for /.git/ somewhere inside the current working directory\n(pwd) ? That's the way mercurial does it currently, and I think that is\na sane thing to do _if_ you want to protect the user from his own\nstupidity.\n"},{"id":"32068","messageId":"Pine.LNX.4.63.0701191600020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6433","inReplyTo":"1169214414.18684.25.camel@localhost.localdomain","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-19T15:00:48Z","receivedAt":"2007-01-19T15:00:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Matthias Kestenholz wrote:\n\n> On Fri, 2007-01-19 at 14:30 +0100, Andreas Ericsson wrote:\n> > Alex Riesen wrote:\n> > > On 1/19/07, Simon 'corecode' Schubert wrote:\n> > >> >\n> > >>\n> > >> % cd .hg && hg status -A .\n> > >> abort: path contains illegal component: .hg\n> > >>\n> > >> I think this is a sensible thing to do.\n> > > \n> > > No, it isn't. It is not unlikely to have repo in repo\n> > > (and some people already have them).\n> > > Mercurial is wrong here.\n> > \n> > For managing repos inside repos (onion repos?) I think it should\n> > be safe to abort if we're not at top-level.\n> > \n> \n> \n> Why not check for /.git/ somewhere inside the current working directory \n> (pwd) ? That's the way mercurial does it currently, and I think that is \n> a sane thing to do _if_ you want to protect the user from his own \n> stupidity.\n\nThere are valid reasons why you might want to have a (possibly \ntemporary) repository _inside_ the GIT_DIR. You'd break these cases.\n\nCiao,\nDscho\n"},{"id":"32073","messageId":"7vtzymhma2.fsf@assigned-by-dhcp.cox.net","threadId":"6433","inReplyTo":"Pine.LNX.4.63.0701191600020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-19T19:03:17Z","receivedAt":"2007-01-19T19:03:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 19 Jan 2007, Matthias Kestenholz wrote:\n> ...\n>> Why not check for /.git/ somewhere inside the current working directory \n>> (pwd) ? That's the way mercurial does it currently, and I think that is \n>> a sane thing to do _if_ you want to protect the user from his own \n>> stupidity.\n>\n> There are valid reasons why you might want to have a (possibly \n> temporary) repository _inside_ the GIT_DIR. You'd break these cases.\n\nYou are right that strstr(here, \"/.git/\") is not a good check.\n\nIf we really care about this problem (and I am not yet starting\nto think we might, but who knows, I reserve the right to change\nmy mind every once in a while), we could make the commands that\ndeal with working trees (that is, among the things under\ndiscussion in this thread, 'git-clean' always is, and\n'git-ls-files' only when it is given options like '-o', '-k',\n'-m', '-i') when the cwd is GIT_DIR or a subdirectory of it.\n\nIf you did something like:\n\n\tmkdir /var/tmp/a\n cd /var/tmp/a\n git init-db\n cd .git\n GIT_DIR=.git git init-db\n git add .\n\tgit ls-files\n\techo junk >garbage\n git clean\n\nthe repository at /var/tmp/a/.git/.git ought to track HEAD,\nconfig and friends in /var/tmp/a/.git directory.\n\nNot that I am saying I think the above is a sensible use case.\n"},{"id":"32381","messageId":"878xfuuhco.wl@mail2.atmark-techno.com","threadId":"6433","inReplyTo":"7vtzymhma2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git ls-files -o under .git/ prints all repository files","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2007-01-23T11:12:39Z","receivedAt":"2007-01-23T11:12:39Z","isPatch":false,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Fri, 19 Jan 2007 11:03:17 -0800,\nJunio C Hamano wrote:\n> \n> Johannes Schindelin writes:\n> \n> > On Fri, 19 Jan 2007, Matthias Kestenholz wrote:\n> > ...\n> >> Why not check for /.git/ somewhere inside the current working directory \n> >> (pwd) ? That's the way mercurial does it currently, and I think that is \n> >> a sane thing to do _if_ you want to protect the user from his own \n> >> stupidity.\n> >\n> > There are valid reasons why you might want to have a (possibly \n> > temporary) repository _inside_ the GIT_DIR. You'd break these cases.\n> \n> You are right that strstr(here, \"/.git/\") is not a good check.\n> \n> If we really care about this problem (and I am not yet starting\n> to think we might, but who knows, I reserve the right to change\n> my mind every once in a while), we could make the commands that\n> deal with working trees (that is, among the things under\n> discussion in this thread, 'git-clean' always is, and\n> 'git-ls-files' only when it is given options like '-o', '-k',\n> '-m', '-i') when the cwd is GIT_DIR or a subdirectory of it.\n\nI believe it should be done. because it used to be safe during v0.9\ntime. most command didn't work if you are not in the root dir of a\nrepo. during the development time, we have been adding feature so that\nwe don't have to be at a root dir to exec git. we just forgot to\ncheck we are under .git, the repo dir.\n\nI assume that we can either have 1) one more bit in struct\ncmd_struct's option field and fail if the command isn't allowed to run\nunder repository dir, or 2) some mechanism to check prefix, the third\nargument of command entry point function, and behave properly.\n\n> If you did something like:\n> \n> \tmkdir /var/tmp/a\n> cd /var/tmp/a\n> git init-db\n> cd .git\n> GIT_DIR=.git git init-db\n> git add .\n> \tgit ls-files\n> \techo junk >garbage\n> git clean\n> \n> the repository at /var/tmp/a/.git/.git ought to track HEAD,\n> config and friends in /var/tmp/a/.git directory.\n\nthis should always work.\n-- \n yashi\n"},{"id":"32386","messageId":"Pine.LNX.4.63.0701231312170.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6433","inReplyTo":"878xfuuhco.wl@mail2.atmark-techno.com","subject":"[PATCH] Commands requiring a work tree must not run in GIT_DIR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T12:30:20Z","receivedAt":"2007-01-23T12:30:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThis patch helps when you accidentally run something like git-clean\nin the git directory instead of the work tree.\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n\tOn Tue, 23 Jan 2007, Yasushi SHOJI wrote:\n\t\n\t> At Fri, 19 Jan 2007 11:03:17 -0800,\n\t> Junio C Hamano wrote:\n\t> > \n\t> > Johannes Schindelin writes:\n\t> > \n\t> > > On Fri, 19 Jan 2007, Matthias Kestenholz wrote:\n\t> > > ...\n\t> > >> Why not check for /.git/ somewhere inside the current \n\t> > >> working directory (pwd) ? That's the way mercurial does it \n\t> > >> currently, and I think that is a sane thing to do _if_ you \n\t> > >> want to protect the user from his own stupidity.\n\t> > >\n\t> > > There are valid reasons why you might want to have a \n\t> > > (possibly temporary) repository _inside_ the GIT_DIR. You'd \n\t> > > break these cases.\n\t> > \n\t> > You are right that strstr(here, \"/.git/\") is not a good check.\n\t> > \n\t> > If we really care about this problem (and I am not yet \n\t> > starting to think we might, but who knows, I reserve the right \n\t> > to change my mind every once in a while), we could make the \n\t> > commands that deal with working trees (that is, among the \n\t> > things under discussion in this thread, 'git-clean' always is, \n\t> > and 'git-ls-files' only when it is given options like '-o', \n\t> > '-k', '-m', '-i') when the cwd is GIT_DIR or a subdirectory of \n\t> > it.\n\t> \n\t> I believe it should be done.\n\n\tI only did that for the mentioned commands; your homework: find \n\tall other commands (or options) which need that.\n\n builtin-ls-files.c | 10 +++++++++-\n builtin-rev-parse.c | 5 +++++\n git-sh-setup.sh | 3 ++-\n git.c | 5 +++--\n 4 files changed, 19 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-ls-files.c b/builtin-ls-files.c\nindex 21c2a6e..ac89eb2 100644\n--- a/builtin-ls-files.c\n+++ b/builtin-ls-files.c\n@@ -323,7 +323,7 @@ static const char ls_files_usage[] =\n int cmd_ls_files(int argc, const char **argv, const char *prefix)\n {\n \tint i;\n-\tint exc_given = 0;\n+\tint exc_given = 0, require_work_tree = 0;\n \tstruct dir_struct dir;\n \n \tmemset(&dir, 0, sizeof(dir));\n@@ -363,14 +363,17 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)\n \t\t}\n \t\tif (!strcmp(arg, \"-m\") || !strcmp(arg, \"--modified\")) {\n \t\t\tshow_modified = 1;\n+\t\t\trequire_work_tree = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"-o\") || !strcmp(arg, \"--others\")) {\n \t\t\tshow_others = 1;\n+\t\t\trequire_work_tree = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"-i\") || !strcmp(arg, \"--ignored\")) {\n \t\t\tdir.show_ignored = 1;\n+\t\t\trequire_work_tree = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"-s\") || !strcmp(arg, \"--stage\")) {\n@@ -379,6 +382,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)\n \t\t}\n \t\tif (!strcmp(arg, \"-k\") || !strcmp(arg, \"--killed\")) {\n \t\t\tshow_killed = 1;\n+\t\t\trequire_work_tree = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--directory\")) {\n@@ -447,6 +451,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)\n \t\tbreak;\n \t}\n \n+\tif (require_work_tree &&\n+\t\t\t(is_bare_repository() || is_inside_git_dir()))\n+\t\tdie(\"This operation must be run in a work tree\");\n+\n \tpathspec = get_pathspec(prefix, argv + i);\n \n \t/* Verify that the pathspec matches the prefix */\ndiff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\nindex 3b716fb..d53deaa 100644\n--- a/builtin-rev-parse.c\n+++ b/builtin-rev-parse.c\n@@ -347,6 +347,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)\n \t\t\t\tprintf(\"%s/.git\\n\", cwd);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--is-inside-git-dir\")) {\n+\t\t\t\tprintf(\"%s\\n\", is_inside_git_dir() ? \"true\"\n+\t\t\t\t\t\t: \"false\");\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strncmp(arg, \"--since=\", 8)) {\n \t\t\t\tshow_datestring(\"--max-age=\", arg+8);\n \t\t\t\tcontinue;\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 6b1c142..9114c49 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -48,7 +48,8 @@ cd_to_toplevel () {\n }\n \n require_work_tree () {\n-\ttest $(is_bare_repository) = false ||\n+\ttest $(is_bare_repository) = false &&\n+\ttest $(git-rev-parse --is-inside-git-dir) = false ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\n }\n \ndiff --git a/git.c b/git.c\nindex 5133a07..2027d1c 100644\n--- a/git.c\n+++ b/git.c\n@@ -302,8 +302,9 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n \t\t\tprefix = setup_git_directory();\n \t\tif (p->option & USE_PAGER)\n \t\t\tsetup_pager();\n-\t\tif ((p->option & NOT_BARE) && is_bare_repository())\n-\t\t\tdie(\"%s cannot be used in a bare git directory\", cmd);\n+\t\tif ((p->option & NOT_BARE) &&\n+\t\t\t\t(is_bare_repository() || is_inside_git_dir()))\n+\t\t\tdie(\"%s must be run in a work tree\", cmd);\n \t\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n \n \t\texit(p->fn(argc, argv, prefix));\n"},{"id":"32511","messageId":"7vodoohcol.fsf@assigned-by-dhcp.cox.net","threadId":"6433","inReplyTo":"Pine.LNX.4.63.0701231312170.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Commands requiring a work tree must not run in GIT_DIR","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-24T11:44:10Z","receivedAt":"2007-01-24T11:44:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> This patch helps when you accidentally run something like git-clean\n> in the git directory instead of the work tree.\n\nI think \"require_work_tree\" reflects what we are trying to do\nmuch better than NOT_BARE. So maybe we should rename NOT_BARE\nto REQUIRE_WORK_TREE.\n\nExisting check function is_bare_repository() is sometimes used\nto see if it is a bare repository regardless of where you are\n(e.g. refs.c::log_ref_write()), so that function can stay as is,\nbut the combined check below (you seem to have a few instances\nin your patch) can be made into a function require_work_tree().\n\n> diff --git a/git.c b/git.c\n> index 5133a07..2027d1c 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -302,8 +302,9 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n> \t\t\tprefix = setup_git_directory();\n> \t\tif (p->option & USE_PAGER)\n> \t\t\tsetup_pager();\n> -\t\tif ((p->option & NOT_BARE) && is_bare_repository())\n> -\t\t\tdie(\"%s cannot be used in a bare git directory\", cmd);\n> +\t\tif ((p->option & NOT_BARE) &&\n> +\t\t\t\t(is_bare_repository() || is_inside_git_dir()))\n> +\t\t\tdie(\"%s must be run in a work tree\", cmd);\n> \t\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n> \n> \t\texit(p->fn(argc, argv, prefix));\n\nSimilar to the \"conditionally require working tree\" you did to\nls-files, \"apply --index\" and perhaps \"apply --cached\" (but this\nis \"perhaps\" --- you _could_ have an index in a bare repository,\nalthough it is debatable if there is a valid use case for it),\ngrep (grep_cache() but perhaps !cached for the same reason),\n\"read-tree -u\", \"rerere\", \"update-index\" (except --index-info\nand friends that feed object names directly without using\nworking tree), should require working tree.\n\nOn the script front, bisect should require working tree, but I\ndo not think anybody is stupid enough to start bisecting in a\nbare repository ;-)\n"},{"id":"32523","messageId":"Pine.LNX.4.63.0701241508510.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6433","inReplyTo":"7vodoohcol.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Commands requiring a work tree must not run in GIT_DIR","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-24T14:14:54Z","receivedAt":"2007-01-24T14:14:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 24 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > This patch helps when you accidentally run something like git-clean\n> > in the git directory instead of the work tree.\n> \n> I think \"require_work_tree\" reflects what we are trying to do\n> much better than NOT_BARE. So maybe we should rename NOT_BARE\n> to REQUIRE_WORK_TREE.\n\nHm. Might make sense.\n\nBut there is a subtle trap here: if a repo is not bare, it does have a \nwork tree. But what we want here actually is NOT_INSIDE_GIT_DIR:\n\nIt is perfectly sensible to run git-pull from inside the git dir, since it \nhas to cd to the top _anyway_. So, git-pull needs a work tree, but does \nnot forbid running from within GIT_DIR.\n\n> Existing check function is_bare_repository() is sometimes used\n> to see if it is a bare repository regardless of where you are\n> (e.g. refs.c::log_ref_write()), so that function can stay as is,\n> but the combined check below (you seem to have a few instances\n> in your patch) can be made into a function require_work_tree().\n> \n> > diff --git a/git.c b/git.c\n> > index 5133a07..2027d1c 100644\n> > --- a/git.c\n> > +++ b/git.c\n> > @@ -302,8 +302,9 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n> > \t\t\tprefix = setup_git_directory();\n> > \t\tif (p->option & USE_PAGER)\n> > \t\t\tsetup_pager();\n> > -\t\tif ((p->option & NOT_BARE) && is_bare_repository())\n> > -\t\t\tdie(\"%s cannot be used in a bare git directory\", cmd);\n> > +\t\tif ((p->option & NOT_BARE) &&\n> > +\t\t\t\t(is_bare_repository() || is_inside_git_dir()))\n> > +\t\t\tdie(\"%s must be run in a work tree\", cmd);\n> > \t\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n> > \n> > \t\texit(p->fn(argc, argv, prefix));\n> \n> Similar to the \"conditionally require working tree\" you did to\n> ls-files, \"apply --index\" and perhaps \"apply --cached\" (but this\n> is \"perhaps\" --- you _could_ have an index in a bare repository,\n> although it is debatable if there is a valid use case for it),\n> grep (grep_cache() but perhaps !cached for the same reason),\n> \"read-tree -u\", \"rerere\", \"update-index\" (except --index-info\n> and friends that feed object names directly without using\n> working tree), should require working tree.\n\nAs I said, maybe we have to introduce DISALLOW_INSIDE_GIT_DIR (which is \nugly, since it is so long, but I cannot think of anything saner), and \nlikewise \"disallow_inside_GIT_DIR\" for scripts.\n\n> On the script front, bisect should require working tree, but I do not \n> think anybody is stupid enough to start bisecting in a bare repository \n> ;-)\n\nOTOH it is really easy:\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 6da31e8..f8a2b64 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -11,6 +11,7 @@ git bisect replay \treplay bisection log\n git bisect log\t\t\tshow bisect log.'\n \n . git-sh-setup\n+require_work_tree\n \n sq() {\n \t@@PERL@@ -e '\n\n\nCiao,\nDscho\n"},{"id":"32568","messageId":"7v7ivcf37p.fsf@assigned-by-dhcp.cox.net","threadId":"6433","inReplyTo":"Pine.LNX.4.63.0701241508510.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Commands requiring a work tree must not run in GIT_DIR","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-24T22:51:38Z","receivedAt":"2007-01-24T22:51:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I think \"require_work_tree\" reflects what we are trying to do\n>> much better than NOT_BARE. So maybe we should rename NOT_BARE\n>> to REQUIRE_WORK_TREE.\n>\n> Hm. Might make sense.\n>\n> But there is a subtle trap here: if a repo is not bare, it does have a \n> work tree. But what we want here actually is NOT_INSIDE_GIT_DIR:\n\nI think we are saying the same thing: \"require to be IN the\nworking tree\" (hence not in \".git/objects\", for example).\n\n> It is perfectly sensible to run git-pull from inside the git dir, since it \n> has to cd to the top _anyway_.\n\nI would not call it \"perfectly sensible\". I never understood\nwhy anybody would want to cd to .git/ in a repository with an\nworking tree while actually working on the files in the working\ntree (e.g. doing merges and pulls and edits and commits) [*1*].\nI would say it is in the \"allowing it is cheap and harmless so\nwhy not\" category.\n\n[*1*] But it's probably just me who almost always is in Emacs;\nswitching to a shell terminal and saying \"cd .git && vi config\"\nis much more expensive than \"^X^F .git/config\").\n"}]}