{"thread":{"id":"33283","subject":"git ate my home directory :-(","startedAt":"2013-03-25T21:38:52Z","lastAt":"2013-03-27T13:05:07Z","messageCount":35,"participants":["Richard Weinberger","Jonathan Nieder","Junio C Hamano","Brandon Casey","Philip Oakley","Duy Nguyen","Jeff King","demerphq","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"212229","messageId":"5150C3EC.6010608@nod.at","threadId":"33283","inReplyTo":null,"subject":"git ate my home directory :-(","fromName":"Richard Weinberger","fromEmail":"richard@nod.at","sentAt":"2013-03-25T21:38:52Z","receivedAt":"2013-03-25T21:38:52Z","isPatch":false,"sender":{"key":"richard@nod.at","avatar":"https://avatars.githubusercontent.com/u/1149549?v=4"},"body":"Hi!\n\nToday I've discovered that on the build server my home directory was empty.\nA post-mortem analysis showed that the git-clean command I've added to my kernel build script\nis the evil doer.\nIn my scripts I'm setting GIT_DIR to use git-fetch and git-reset without changing the\ncurrent working directory all the time.\nBut calling git-clean with GIT_DIR acts basically like a \"rm -Rf .\".\n\nHere a small demo:\n\ntest@linux:~> git --version\ngit version 1.8.1.4\ntest@linux:~> ls\ntest@linux:~> touch a b c d e\ntest@linux:~> mkdir x\ntest@linux:~> cd x\ntest@linux:~/x> git init\nInitialized empty Git repository in /home/test/x/.git/\ntest@linux:~/x> cd ..\ntest@linux:~> ls\na b c d e x\ntest@linux:~> export GIT_DIR=/home/test/x/.git/\ntest@linux:~> git clean -d -f\nRemoving a\nRemoving b\nRemoving c\nRemoving d\nRemoving e\nRemoving x/\ntest@linux:~> ls\ntest@linux:~>\ntest@linux:~> # :-(\n\nIs this behavior intended?\n\nThanks,\n//richard\n"},{"id":"212231","messageId":"20130325214343.GF1414@google.com","threadId":"33283","inReplyTo":"5150C3EC.6010608@nod.at","subject":"Re: git ate my home directory :-(","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T21:43:43Z","receivedAt":"2013-03-25T21:43:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRichard Weinberger wrote:\n\n> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without changing the\n> current working directory all the time.\n\nYeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\nGIT_DIR is explicitly set.\n\nIn git versions including the patch 2cd83d10bb6b (setup: suppress\nimplicit \".\" work-tree for bare repos, 2013-03-08, currently in \"next\"\nbut not \"master\"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this\nbehavior.\n\nThanks for a useful example, and sorry for the trouble.\n\nSincerely,\nJonathan\n"},{"id":"212237","messageId":"7vfvzjw334.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"20130325214343.GF1414@google.com","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T22:02:07Z","receivedAt":"2013-03-25T22:02:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> In git versions including the patch 2cd83d10bb6b (setup: suppress\n> implicit \".\" work-tree for bare repos, 2013-03-08, currently in \"next\"\n> but not \"master\"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this\n> behavior.\n\nWAT?\n"},{"id":"212238","messageId":"7vboa7w2vm.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"20130325214343.GF1414@google.com","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T22:06:37Z","receivedAt":"2013-03-25T22:06:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Richard Weinberger wrote:\n>\n>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without changing the\n>> current working directory all the time.\n>\n> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n> GIT_DIR is explicitly set.\n\nAnd it *WILL* be that way til the end of time. Unless you are at\nthe top level of your working tree, you are supposed to tell where\nthe top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n\nAnd that is the answer you should be giving here, not implicit\nstuff, which is an implementation detail to help aliases. I do not\nknow how things will break when the end user sets and exports it to\nthe environment, and I do not think we would want to make any\npromise on how it works.\n"},{"id":"212239","messageId":"20130325220822.GG1414@google.com","threadId":"33283","inReplyTo":"7vfvzjw334.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T22:08:22Z","receivedAt":"2013-03-25T22:08:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> In git versions including the patch 2cd83d10bb6b (setup: suppress\n>> implicit \".\" work-tree for bare repos, 2013-03-08, currently in \"next\"\n>> but not \"master\"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this\n>> behavior.\n>\n> WAT?\n\nIs that false?\n\nIf I understand the history correctly, the ability to set the GIT_DIR\nenvvar was meant to allow a person to keep their .git directory outside\nthe worktree. So you can do:\n\n\tgit init my-favorite-repo\n\tcd my-favorite-repo\n\t...work as usual...\n\n\t# cleaning time!\n\tmv .git ~/my-favorite-repo-metadata.git\n\tGIT_DIR=$HOME/my-favorite-repo-metadata.git; export GIT_DIR\n\t... work as usual...\n\nIf you want to set GIT_DIR and treat it as a bare repository, the\nsane way to do that is simply\n\n\tcd ~/my-favorite-bare-repository.git\n\t... use git as usual ...\n\nBut if something (for example relative paths used by your script)\nties your cwd somewhere else, you might really want to do\n\n\tGIT_DIR=~/my-favorite-bare-repository.git; export GIT_DIR\n\t... work as usual ...\n\nand as a side effect of Jeff's patch there is now a mechanism to do\nthat:\n\n\tGIT_IMPLICIT_WORK_TREE=0; export GIT_IMPLICIT_WORK_TREE\n\tGIT_DIR=~/my-favorite-bare-repository.git; export GIT_DIR\n\t... work as usual ...\n\nThis is of course unsafe because it ties your usage to a specific\nversion of git. And the variable is not advertised in the\ndocumentation.\n"},{"id":"212240","messageId":"5150CB34.1030008@nod.at","threadId":"33283","inReplyTo":"7vboa7w2vm.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Richard Weinberger","fromEmail":"richard@nod.at","sentAt":"2013-03-25T22:09:56Z","receivedAt":"2013-03-25T22:09:56Z","isPatch":false,"sender":{"key":"richard@nod.at","avatar":"https://avatars.githubusercontent.com/u/1149549?v=4"},"body":"Am 25.03.2013 23:06, schrieb Junio C Hamano:\n> Jonathan Nieder writes:\n>\n>> Richard Weinberger wrote:\n>>\n>>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without changing the\n>>> current working directory all the time.\n>>\n>> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n>> GIT_DIR is explicitly set.\n>\n> And it *WILL* be that way til the end of time. Unless you are at\n> the top level of your working tree, you are supposed to tell where\n> the top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n>\n> And that is the answer you should be giving here, not implicit\n> stuff, which is an implementation detail to help aliases. I do not\n> know how things will break when the end user sets and exports it to\n> the environment, and I do not think we would want to make any\n> promise on how it works.\n>\n\nOkay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?\nI've always set only GIT_DIR because it just worked (till today...).\n\nThanks,\n//richard\n"},{"id":"212241","messageId":"20130325221355.GH1414@google.com","threadId":"33283","inReplyTo":"7vboa7w2vm.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T22:13:55Z","receivedAt":"2013-03-25T22:13:55Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> I do not\n> know how things will break when the end user sets and exports it to\n> the environment, and I do not think we would want to make any\n> promise on how it works.\n\nThat's a reasonable desire, and it means it's a good thing we noticed\nthis before the envvar escaped to \"master\". People *will* use such\nexposed interfaces unless they are clearly marked as internal. That's\njust a fact of life.\n\nHere's a rough patch to hopefully improve matters.\n\nLonger term, it would be nice to have something like\nGIT_IMPLICIT_WORK_TREE exposed to let scripts cache the result of the\nsearch for .git. Maybe something like \"GIT_BARE=(arbitrary value)\"\nwould be a good interface.\n\nSigned-off-by: Jonathan Nieder \n---\n\ndiff --git a/cache.h b/cache.h\nindex 59e5b53..8f92b6d 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -377,7 +377,7 @@ static inline enum object_type object_type(unsigned int mode)\n * of this, but we use it internally to communicate to sub-processes that we\n * are in a bare repo. If not set, defaults to true.\n */\n-#define GIT_IMPLICIT_WORK_TREE_ENVIRONMENT \"GIT_IMPLICIT_WORK_TREE\"\n+#define GIT_IMPLICIT_WORK_TREE_ENVIRONMENT \"GIT_INTERNAL_IMPLICIT_WORK_TREE\"\n \n /*\n * Repository-local GIT_* environment variables; these will be cleared\n"},{"id":"212242","messageId":"20130325221512.GI1414@google.com","threadId":"33283","inReplyTo":"5150CB34.1030008@nod.at","subject":"Re: git ate my home directory :-(","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T22:15:13Z","receivedAt":"2013-03-25T22:15:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Richard Weinberger wrote:\n\n> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?\n> I've always set only GIT_DIR because it just worked (till today...).\n\nchdir-ing into the git repo without setting any GIT_* vars is probably\nthe simplest way to go.\n"},{"id":"212243","messageId":"7v7gkvw2gp.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"20130325220822.GG1414@google.com","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T22:15:34Z","receivedAt":"2013-03-25T22:15:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>\n>>> In git versions including the patch 2cd83d10bb6b (setup: suppress\n>>> implicit \".\" work-tree for bare repos, 2013-03-08, currently in \"next\"\n>>> but not \"master\"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this\n>>> behavior.\n>>\n>> WAT?\n>\n> Is that false?\n>\n> If I understand the history correctly, the ability to set the GIT_DIR\n> envvar was meant to allow a person to keep their .git directory outside\n> the worktree. So you can do:\n>\n> \tgit init my-favorite-repo\n> \tcd my-favorite-repo\n> \t...work as usual...\n>\n> \t# cleaning time!\n> \tmv .git ~/my-favorite-repo-metadata.git\n> \tGIT_DIR=$HOME/my-favorite-repo-metadata.git; export GIT_DIR\n> \t... work as usual...\n\n... as usual except that you have to be at the top.\n\nAnd that is why GIT_WORK_TREE was invented, so that you can anchor\nwhere the top of the tree is with that variable and then chdir\naround into its subdirectories.\n\nAlso later we added core.worktree so that $GIT_DIR/config can say\nwhere its associated working tree is.\n\n> This is of course unsafe because it ties your usage to a specific\n> version of git. And the variable is not advertised in the\n> documentation.\n\nWe decided not to advitise it exactly because we do not intend to\nguarantee that will be the way that variable will work. It is an\nimplementation detail of that \"alias\" stuff in the topic it\naddresses.\n\nThe documented way is to point at the tip with GIT_WORK_TREE.\n"},{"id":"212244","messageId":"7v38vjw28v.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"5150CB34.1030008@nod.at","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T22:20:16Z","receivedAt":"2013-03-25T22:20:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Weinberger writes:\n\n> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?\n> I've always set only GIT_DIR because it just worked (till today...).\n\nThat means you never run your script inside a subdirectory ;-)\n\nIf your $GIT_DIR is tied to a single working tree, a simpler way\nwould be to add\n\n\t[core]\n\t\tworktree = /path/to/the/work/tree/\n\nto $GIT_DIR/config.\n"},{"id":"212245","messageId":"CA+sFfMexDR50b5FnJ-4MS8pxPXmg0CCbzCLVc3vx5XjfqdY1nQ@mail.gmail.com","threadId":"33283","inReplyTo":"20130325221355.GH1414@google.com","subject":"Re: git ate my home directory :-(","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-03-25T22:21:11Z","receivedAt":"2013-03-25T22:21:11Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Mon, Mar 25, 2013 at 3:13 PM, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n>\n>> I do not\n>> know how things will break when the end user sets and exports it to\n>> the environment, and I do not think we would want to make any\n>> promise on how it works.\n>\n> That's a reasonable desire, and it means it's a good thing we noticed\n> this before the envvar escaped to \"master\". People *will* use such\n> exposed interfaces unless they are clearly marked as internal. That's\n> just a fact of life.\n>\n> Here's a rough patch to hopefully improve matters.\n>\n> Longer term, it would be nice to have something like\n> GIT_IMPLICIT_WORK_TREE exposed to let scripts cache the result of the\n> search for .git. Maybe something like \"GIT_BARE=(arbitrary value)\"\n> would be a good interface.\n>\n> Signed-off-by: Jonathan Nieder \n> ---\n>\n> diff --git a/cache.h b/cache.h\n> index 59e5b53..8f92b6d 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -377,7 +377,7 @@ static inline enum object_type object_type(unsigned int mode)\n> * of this, but we use it internally to communicate to sub-processes that we\n> * are in a bare repo. If not set, defaults to true.\n> */\n> -#define GIT_IMPLICIT_WORK_TREE_ENVIRONMENT \"GIT_IMPLICIT_WORK_TREE\"\n> +#define GIT_IMPLICIT_WORK_TREE_ENVIRONMENT \"GIT_INTERNAL_IMPLICIT_WORK_TREE\"\n\nMaybe the environment variable for internal-use-only should be\nprefixed with an underscore?\n\n-Brandon\n"},{"id":"212246","messageId":"5150CF3E.9020808@nod.at","threadId":"33283","inReplyTo":"7v38vjw28v.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Richard Weinberger","fromEmail":"richard@nod.at","sentAt":"2013-03-25T22:27:10Z","receivedAt":"2013-03-25T22:27:10Z","isPatch":false,"sender":{"key":"richard@nod.at","avatar":"https://avatars.githubusercontent.com/u/1149549?v=4"},"body":"Am 25.03.2013 23:20, schrieb Junio C Hamano:\n> Richard Weinberger writes:\n>\n>> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?\n>> I've always set only GIT_DIR because it just worked (till today...).\n>\n> That means you never run your script inside a subdirectory ;-)\n>\n> If your $GIT_DIR is tied to a single working tree, a simpler way\n> would be to add\n>\n> \t[core]\n> \t\tworktree = /path/to/the/work/tree/\n\nI've used GIT_DIR in my scripts because changing the current working directory\nwithin bash scripts often causes problem with other commands.\nThat's why I've used patters like:\nexport GIT_DIR=/path/to/repo/.git\ngit fetch ...\ndo_this\ndo_that\ngit reset --hard FETCH_HEAD\ndo_foo\ngit whatever\n\nexport GIT_DIR=/path/to/another/repo/.git\ngit fetch ...\n...\n\nBut from now on I'll simply cd into the git repo...\n\nThanks,\n//richard\n"},{"id":"212270","messageId":"384BCFE976364F1EA6E56306566D003A@PhilipOakley","threadId":"33283","inReplyTo":"7vboa7w2vm.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-03-26T07:57:14Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Monday, March 25, 2013 10:06 PM\n> Jonathan Nieder writes:\n>\n>> Richard Weinberger wrote:\n>>\n>>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset \n>>> without changing the\n>>> current working directory all the time.\n>>\n>> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n>> GIT_DIR is explicitly set.\n>\n> And it *WILL* be that way til the end of time. Unless you are at\n> the top level of your working tree, you are supposed to tell where\n> the top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n\nShould this important warning be part of the git(1) documentation on the \nenvironment variables (and possibly other places) given the consequences \nof this case? It wasn't something I'd appreciated from a simple reading.\n\n>\n> And that is the answer you should be giving here, not implicit\n> stuff, which is an implementation detail to help aliases. I do not\n> know how things will break when the end user sets and exports it to\n> the environment, and I do not think we would want to make any\n> promise on how it works.\n> --\nPhilip \n"},{"id":"212276","messageId":"20130326094844.GA32583@duynguyen-vnpc.dek-tpc.internal","threadId":"33283","inReplyTo":"384BCFE976364F1EA6E56306566D003A@PhilipOakley","subject":"Re: git ate my home directory :-(","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-03-26T09:48:44Z","receivedAt":"2013-03-26T09:48:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 26, 2013 at 08:02:30AM -0000, Philip Oakley wrote:\n> >> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n> >> GIT_DIR is explicitly set.\n> >\n> > And it *WILL* be that way til the end of time. Unless you are at\n> > the top level of your working tree, you are supposed to tell where\n> > the top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n> \n> Should this important warning be part of the git(1) documentation on the \n> environment variables (and possibly other places) given the consequences \n> of this case? It wasn't something I'd appreciated from a simple reading.\n\nSomething like this, maybe?\n\n-- 8< --\nSubject: [PATCH] git.txt: document the implicit working tree setting with GIT_DIR\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Documentation/git.txt | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 7efaa59..ce55abf 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -671,6 +671,8 @@ Git so take care if using Cogito etc.\n \tspecifies a path to use instead of the default `.git`\n \tfor the base of the repository.\n \tThe '--git-dir' command-line option also sets this value.\n+\tIf neither GIT_WORK_TREE nor '--work-tree' is set, the\n+\tcurrent directory will become the working tree.\n \n 'GIT_WORK_TREE'::\n \tSet the path to the working tree. The value will not be\n-- \n1.8.2.82.gc24b958\n-- 8< --\n"},{"id":"212285","messageId":"51519DA0.4090201@nod.at","threadId":"33283","inReplyTo":"384BCFE976364F1EA6E56306566D003A@PhilipOakley","subject":"Re: git ate my home directory :-(","fromName":"Richard Weinberger","fromEmail":"richard@nod.at","sentAt":"2013-03-26T13:07:44Z","receivedAt":"2013-03-26T13:07:44Z","isPatch":false,"sender":{"key":"richard@nod.at","avatar":"https://avatars.githubusercontent.com/u/1149549?v=4"},"body":"Am 26.03.2013 09:02, schrieb Philip Oakley:\n> From: \"Junio C Hamano\" \n> Sent: Monday, March 25, 2013 10:06 PM\n>> Jonathan Nieder writes:\n>>\n>>> Richard Weinberger wrote:\n>>>\n>>>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without changing the\n>>>> current working directory all the time.\n>>>\n>>> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n>>> GIT_DIR is explicitly set.\n>>\n>> And it *WILL* be that way til the end of time. Unless you are at\n>> the top level of your working tree, you are supposed to tell where\n>> the top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n>\n> Should this important warning be part of the git(1) documentation on the environment variables (and possibly other places) given the consequences of this case? It wasn't something\n> I'd appreciated from a simple reading.\n\nBTW: Can't we change git-clean such that it will not delete any files if GIT_DIR is set and GIT_WORK_TREE is \".\"?\n\nThanks,\n//richard\n"},{"id":"212288","messageId":"20130326145637.GA3822@sigill.intra.peff.net","threadId":"33283","inReplyTo":"51519DA0.4090201@nod.at","subject":"Re: git ate my home directory :-(","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T14:56:37Z","receivedAt":"2013-03-26T14:56:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:\n\n> >Should this important warning be part of the git(1) documentation on\n> >the environment variables (and possibly other places) given the\n> >consequences of this case? It wasn't something\n> >I'd appreciated from a simple reading.\n> \n> BTW: Can't we change git-clean such that it will not delete any files\n> if GIT_DIR is set and GIT_WORK_TREE is \".\"?s\n\nWe could, but that would break the existing behavior for other people\n(and I assume you mean \"when GIT_WORK_TREE is not set at all\", as I\nwould think GIT_WORK_TREE=. is explicit enough).\n\nI am sympathetic to your data loss, but I wonder how common a problem it\nis in practice. Git-clean already does a dry-run by default; you have to\ngive it `-f`. This is the first such report we've had. This seems more\nakin to \"oops, I accidentally ran `rm -rf` in the wrong directory\". Yes,\nit's catastrophic, but at some point you have to accept that deleting\nfiles is what rm (and git-clean) does; you can only put so many safety\nhoops in place.\n\nI don't know. It's an uncommon enough case that we could deprecate\n\"GIT_WORK_TREE is implicitly `.`\" entirely, but I think it would need a\ndeprecation period, and a way to get the same behavior (e.g., allowing\n\"GIT_WORK_TREE=.\").\n\n-Peff\n"},{"id":"212289","messageId":"20130326150428.GA3847@sigill.intra.peff.net","threadId":"33283","inReplyTo":"20130326094844.GA32583@duynguyen-vnpc.dek-tpc.internal","subject":"Re: git ate my home directory :-(","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T15:04:28Z","receivedAt":"2013-03-26T15:04:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> Something like this, maybe?\n> \n> -- 8< --\n> Subject: [PATCH] git.txt: document the implicit working tree setting with GIT_DIR\n> \n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Documentation/git.txt | 2 ++\n> 1 file changed, 2 insertions(+)\n> \n> diff --git a/Documentation/git.txt b/Documentation/git.txt\n> index 7efaa59..ce55abf 100644\n> --- a/Documentation/git.txt\n> +++ b/Documentation/git.txt\n> @@ -671,6 +671,8 @@ Git so take care if using Cogito etc.\n> \tspecifies a path to use instead of the default `.git`\n> \tfor the base of the repository.\n> \tThe '--git-dir' command-line option also sets this value.\n> +\tIf neither GIT_WORK_TREE nor '--work-tree' is set, the\n> +\tcurrent directory will become the working tree.\n\nI think this is a good thing to mention, but a few nits:\n\n 1. core.worktree is another way of setting it\n\n 2. This can also be overridden by --bare (at least in \"next\").\n\n 3. I think having core.bare set will also override this\n\n-Peff\n"},{"id":"212293","messageId":"7vr4j2t94l.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"20130326150428.GA3847@sigill.intra.peff.net","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-26T16:32:10Z","receivedAt":"2013-03-26T16:32:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:\n>\n>> Something like this, maybe?\n>> \n>> -- 8< --\n>> Subject: [PATCH] git.txt: document the implicit working tree setting with GIT_DIR\n>> \n>> Signed-off-by: Nguyễn Thái Ngọc Duy \n>> ---\n>> Documentation/git.txt | 2 ++\n>> 1 file changed, 2 insertions(+)\n>> \n>> diff --git a/Documentation/git.txt b/Documentation/git.txt\n>> index 7efaa59..ce55abf 100644\n>> --- a/Documentation/git.txt\n>> +++ b/Documentation/git.txt\n>> @@ -671,6 +671,8 @@ Git so take care if using Cogito etc.\n>> \tspecifies a path to use instead of the default `.git`\n>> \tfor the base of the repository.\n>> \tThe '--git-dir' command-line option also sets this value.\n>> +\tIf neither GIT_WORK_TREE nor '--work-tree' is set, the\n>> +\tcurrent directory will become the working tree.\n>\n> I think this is a good thing to mention, but a few nits:\n>\n> 1. core.worktree is another way of setting it\n>\n> 2. This can also be overridden by --bare (at least in \"next\").\n>\n> 3. I think having core.bare set will also override this\n\nYeah. And sorry I kept typing alias. I obviously meant \"bare\"; the\nuser visible symptom is closely linked to the use of alias, but the\nmost important aspect of the change in 2cd83d10bb6b (setup: suppress\nimplicit \".\" work-tree for bare repos, 2013-03-08) is about being in\na bare repository where by definition working tree does not exist.\n"},{"id":"212298","messageId":"5151D589.2000002@nod.at","threadId":"33283","inReplyTo":"20130326145637.GA3822@sigill.intra.peff.net","subject":"Re: git ate my home directory :-(","fromName":"Richard Weinberger","fromEmail":"richard@nod.at","sentAt":"2013-03-26T17:06:17Z","receivedAt":"2013-03-26T17:06:17Z","isPatch":false,"sender":{"key":"richard@nod.at","avatar":"https://avatars.githubusercontent.com/u/1149549?v=4"},"body":"Am 26.03.2013 15:56, schrieb Jeff King:\n> On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:\n>\n>>> Should this important warning be part of the git(1) documentation on\n>>> the environment variables (and possibly other places) given the\n>>> consequences of this case? It wasn't something\n>>> I'd appreciated from a simple reading.\n>>\n>> BTW: Can't we change git-clean such that it will not delete any files\n>> if GIT_DIR is set and GIT_WORK_TREE is \".\"?s\n>\n> We could, but that would break the existing behavior for other people\n> (and I assume you mean \"when GIT_WORK_TREE is not set at all\", as I\n> would think GIT_WORK_TREE=. is explicit enough).\n\nIs there a valid use case to call git-clean with GIT_DIR set but GIT_WORK_TREE\nnot (or to .\"\")?\nIt will delete \".\" ;)\n\n> I am sympathetic to your data loss, but I wonder how common a problem it\n> is in practice. Git-clean already does a dry-run by default; you have to\n> give it `-f`. This is the first such report we've had. This seems more\n> akin to \"oops, I accidentally ran `rm -rf` in the wrong directory\". Yes,\n> it's catastrophic, but at some point you have to accept that deleting\n> files is what rm (and git-clean) does; you can only put so many safety\n> hoops in place.\n\nThe data loss was not too bad. I was able to restore anything within 2 hours.\nBut was kinda shocked that git-clean deletes files outside my git tree.\nI'm aware of -d. But in my case it happened within a fully automated script.\nI simply thought GIT_DIR=.. git-clean -f -d does the right thing...\n\n> I don't know. It's an uncommon enough case that we could deprecate\n> \"GIT_WORK_TREE is implicitly `.`\" entirely, but I think it would need a\n> deprecation period, and a way to get the same behavior (e.g., allowing\n> \"GIT_WORK_TREE=.\").\n\nYeah, this sounds sane.\n\nThanks,\n//richard\n\nP.s: I've told this story to some friends and co-workers which use git like me very day.\nAll of them were shocked about the behavior of git-clean and GIT_DIR.\n"},{"id":"212299","messageId":"CANgJU+Wihp=rSQevij6R7SnZtW8UpDtRpFYE00aKKAwiYi9Q_Q@mail.gmail.com","threadId":"33283","inReplyTo":"5151D589.2000002@nod.at","subject":"Re: git ate my home directory :-(","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2013-03-26T17:20:09Z","receivedAt":"2013-03-26T17:20:09Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 26 March 2013 18:06, Richard Weinberger wrote:\n> P.s: I've told this story to some friends and co-workers which use git like\n> me very day.\n> All of them were shocked about the behavior of git-clean and GIT_DIR.\n\nSeconded. At $work lots of people started asking anxious questions\nabout this. It was suggested it is a potential security hole, although\nI am not sure I agree, but the general idea being that if you could\nmanage to set this var in someones environment then they might use git\nto do real damage to a system. (The counterargument being that if you\ncan set that in someones environment you can do worse already... But\nim a not a security type so I cant say)\n\nAs a knee-jerk response we will be armoring various scripts we have\nthat use git automatically to refuse to run if GIT_DIR is set. I\nsuspect a lot of people will be doing the same.\n\ncheers,\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"212300","messageId":"20130326174059.GA10383@sigill.intra.peff.net","threadId":"33283","inReplyTo":"5151D589.2000002@nod.at","subject":"Re: git ate my home directory :-(","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T17:41:00Z","receivedAt":"2013-03-26T17:41:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 06:06:17PM +0100, Richard Weinberger wrote:\n\n> >We could, but that would break the existing behavior for other people\n> >(and I assume you mean \"when GIT_WORK_TREE is not set at all\", as I\n> >would think GIT_WORK_TREE=. is explicit enough).\n> \n> Is there a valid use case to call git-clean with GIT_DIR set but GIT_WORK_TREE\n> not (or to .\"\")?\n> It will delete \".\" ;)\n\nYes, setting GIT_DIR but not GIT_WORK_TREE has always been a valid way\nto work on a repository where you do not want the working tree polluted\nwith your .git file. It's not a common setup, but people do use it.\nE.g., you might keep ~/mail as a git repo, but do not want the presence\nof ~/mail/.git to confuse your mail tools. You can keep ~/git/mail.git\nas just a repository, and do \"cd ~/mail && GIT_DIR=~/git/mail.git git\nfoo\" (or \"git --git-dir=~git/mail.git foo\").\n\nLater, we introduced GIT_WORK_TREE (and core.worktree), which provided\nanother way of doing the same thing (instead of the \"cd\", you could set\nGIT_WORK_TREE). For the most part, I'd expect setting core.worktree to\nbe the simplest for such setups, as once it is set, you can just do \"cd\n~/git/mail.git git foo\", and everything should just work.\n\nWe never deprecated the original \"GIT_DIR without GIT_WORK_TREE means\n'.' is the implicit worktree\" behavior, as nobody ever complained, and\nit would break existing users of the feature.\n\nWe could do so now, as long as we provide an escape hatch (and I think\nspelling that hatch as GIT_WORK_TREE=. is probably sane, but I am open\nto other suggestions). And in general we try to avoid such breakage\nwithout a deprecation period to give people time to fix their scripts\nand workflows.\n\n> But was kinda shocked that git-clean deletes files outside my git tree.\n> I'm aware of -d. But in my case it happened within a fully automated script.\n> I simply thought GIT_DIR=.. git-clean -f -d does the right thing...\n\nIt did do the right thing; just not the one you expected. :)\n\nThe problem is not with \"clean\", which just happens to be a destructive\ncommand, but rather with the notion of what the git tree is when you\nprovide GIT_DIR. Though clean is an obvious problematic command,\nsomething like \"git reset --hard\" could also be destructive. I don't\nthink it makes sense to do any fix that is specific to clean. If there\nis a fix to be done, it should be about making the working tree lookup\nalgorithm more obvious.\n\n-Peff\n"},{"id":"212301","messageId":"20130326174804.GB10383@sigill.intra.peff.net","threadId":"33283","inReplyTo":"CANgJU+Wihp=rSQevij6R7SnZtW8UpDtRpFYE00aKKAwiYi9Q_Q@mail.gmail.com","subject":"Re: git ate my home directory :-(","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T17:48:04Z","receivedAt":"2013-03-26T17:48:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:\n\n> Seconded. At $work lots of people started asking anxious questions\n> about this. It was suggested it is a potential security hole, although\n> I am not sure I agree, but the general idea being that if you could\n> manage to set this var in someones environment then they might use git\n> to do real damage to a system. (The counterargument being that if you\n> can set that in someones environment you can do worse already... But\n> im a not a security type so I cant say)\n\nIMHO, that is just silly. Setting GIT_WORK_TREE=/ would be just as\ndestructive. Or GIT_EXTERNAL_DIFF=\"rm -rf /\" (or GIT_PAGER, etc).\nIf there is a danger to the implicit-workdir behavior, it is due to\naccidental usage, not from a malicious attack.\n\n-Peff\n"},{"id":"212302","messageId":"7vfvzit439.fsf@alter.siamese.dyndns.org","threadId":"33283","inReplyTo":"20130326174059.GA10383@sigill.intra.peff.net","subject":"Re: git ate my home directory :-(","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-26T18:20:58Z","receivedAt":"2013-03-26T18:20:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yes, setting GIT_DIR but not GIT_WORK_TREE has always been a valid way\n> to work on a repository where you do not want the working tree polluted\n> with your .git file. It's not a common setup, but people do use it.\n> E.g., you might keep ~/mail as a git repo, but do not want the presence\n> of ~/mail/.git to confuse your mail tools. You can keep ~/git/mail.git\n> as just a repository, and do \"cd ~/mail && GIT_DIR=~/git/mail.git git\n> foo\" (or \"git --git-dir=~git/mail.git foo\").\n>\n> Later, we introduced GIT_WORK_TREE (and core.worktree), which provided\n> another way of doing the same thing (instead of the \"cd\", you could set\n> GIT_WORK_TREE).\n\nA small correction is necessary as the above invites confusion.\n\nWhen you are in ~/mail/subdir, because GIT_DIR alone does not give\nyou to specify where the root-level of the working tree is, you had\nto \"cd ..\" before running \"GIT_DIR=~/git/mail.git git ...\". By\nsetting GIT_WORK_TREE to point at ~/mail once, you can freely chdir\naround inside subdirectories of ~/mail without losing sight of where\nthe root-level is, and if your ~/git/mail.git is tied to a single\nworking tree (and that is true in this example, it is always ~/mail),\nyou can even set core.worktree in ~/git/mail.git/config.\n\nThese two mechanisms are *not* about allowing you to run git from\nany random place, e.g. \"/tmp\".\n\n> For the most part, I'd expect setting core.worktree to be the\n> simplest for such setups, as once it is set, you can just do \"cd\n> ~/git/mail.git git foo\", and everything should just work.\n\nYes.\n\n> We could do so now, as long as we provide an escape hatch (and I think\n> spelling that hatch as GIT_WORK_TREE=. is probably sane, but I am open\n> to other suggestions).\n\nIf we were to do so, GIT_WORK_TREE=. would be the most sensible, but\nI do not think it is worth breaking. Why do these people set GIT_DIR\nwithout setting GIT_WORK_TREE in the first place?\n\nThat is the source of the confusion. Perhaps some random but\npopular websites are spreading bad pieces of advice?\n\n> The problem is not with \"clean\", which just happens to be a destructive\n> command, but rather with the notion of what the git tree is when you\n> provide GIT_DIR.\n\nYes, \"git add .\" would happily add random cruft to your index, which\nis equally bad.\n"},{"id":"212313","messageId":"CANgJU+U-M9zUUzRNJ=r=Utp7BMhGO37wDQAx8et0W23P3CTegA@mail.gmail.com","threadId":"33283","inReplyTo":"20130326174804.GB10383@sigill.intra.peff.net","subject":"Re: git ate my home directory :-(","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2013-03-26T19:08:39Z","receivedAt":"2013-03-26T19:08:39Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 26 March 2013 18:48, Jeff King wrote:\n> On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:\n>\n>> Seconded. At $work lots of people started asking anxious questions\n>> about this. It was suggested it is a potential security hole, although\n>> I am not sure I agree, but the general idea being that if you could\n>> manage to set this var in someones environment then they might use git\n>> to do real damage to a system. (The counterargument being that if you\n>> can set that in someones environment you can do worse already... But\n>> im a not a security type so I cant say)\n>\n> IMHO, that is just silly. Setting GIT_WORK_TREE=/ would be just as\n> destructive. Or GIT_EXTERNAL_DIFF=\"rm -rf /\" (or GIT_PAGER, etc).\n> If there is a danger to the implicit-workdir behavior, it is due to\n> accidental usage, not from a malicious attack.\n\nYeah, that was my line of reasoning too. I'm glad to hear you agree.\n\ncheers\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"212322","messageId":"20130326200851.GA22080@sigill.intra.peff.net","threadId":"33283","inReplyTo":"7vfvzit439.fsf@alter.siamese.dyndns.org","subject":"Re: git ate my home directory :-(","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T20:08:51Z","receivedAt":"2013-03-26T20:08:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 11:20:58AM -0700, Junio C Hamano wrote:\n\n> When you are in ~/mail/subdir, because GIT_DIR alone does not give\n> you to specify where the root-level of the working tree is, you had\n> to \"cd ..\" before running \"GIT_DIR=~/git/mail.git git ...\". By\n> setting GIT_WORK_TREE to point at ~/mail once, you can freely chdir\n> around inside subdirectories of ~/mail without losing sight of where\n> the root-level is, and if your ~/git/mail.git is tied to a single\n> working tree (and that is true in this example, it is always ~/mail),\n> you can even set core.worktree in ~/git/mail.git/config.\n\nYeah, I did not talk about moving around to multiple working trees with\nthe same GIT_DIR. I have done that, but I do not know of a workflow\nwhere it is a good practice, and not just a one-off hack.\n\n> > We could do so now, as long as we provide an escape hatch (and I think\n> > spelling that hatch as GIT_WORK_TREE=. is probably sane, but I am open\n> > to other suggestions).\n> \n> If we were to do so, GIT_WORK_TREE=. would be the most sensible, but\n> I do not think it is worth breaking. Why do these people set GIT_DIR\n> without setting GIT_WORK_TREE in the first place?\n\nI don't think there is a good reason. The argument, as I see it, is\nmainly that doing so can be confusing and destructive, and there is not\na big benefit to allowing it.\n\nI am not sure I am convinced it is worth the breakage, either. Curious\nas to what the code would look like, I made a straw-man series, which\nwill follow. Note that I am not suggesting we do this, but still merely\nthinking about the idea.\n\nNotably, at the end of the series a number of tests fail. A few of them\nare testing the GIT_DIR behavior explicitly (I fixed up t1510, but did\nnot hunt down all of the spots), but a few of them are legitimate\nbreakages in scripts. For example, difftool is broken because it sets\nGIT_DIR. That gives us an indication of what kinds of breakages we would\nsee in real-world third-party scripts.\n\n> > The problem is not with \"clean\", which just happens to be a destructive\n> > command, but rather with the notion of what the git tree is when you\n> > provide GIT_DIR.\n> \n> Yes, \"git add .\" would happily add random cruft to your index, which\n> is equally bad.\n\nEh, I would say it is bad, but not equally bad to removing your entire\nhome directory. ;)\n\n-Peff\n"},{"id":"212323","messageId":"20130326201140.GA22522@sigill.intra.peff.net","threadId":"33283","inReplyTo":"20130326200851.GA22080@sigill.intra.peff.net","subject":"[DONOTAPPLY PATCH 1/3] environment: set GIT_WORK_TREE when we figure out work tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T20:11:40Z","receivedAt":"2013-03-26T20:11:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"If we end up in a sub-process where GIT_WORK_TREE is not set\nbut GIT_DIR is, we assume the current directory is the root\nof the working tree. Since future patches will change that\nassumption, let's defensively start setting GIT_WORK_TREE\nexplicitly.\n\nSigned-off-by: Jeff King \n---\nI didn't test this very well (in fact, I only noticed the issue after\nhaving written the other two patches, as without it, those ones break\nevery external command which wants to run in a working tree). I would\nnot be surprised if there is some code path which sets GIT_DIR but not\nthis, or if there is some other weird fallout from having GIT_WORK_TREE\nset explicitly.\n\n environment.c | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/environment.c b/environment.c\nindex 92c5dff..be2e509 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -194,6 +194,7 @@ void set_git_work_tree(const char *new_work_tree)\n \t}\n \tgit_work_tree_initialized = 1;\n \twork_tree = xstrdup(real_path(new_work_tree));\n+\tsetenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);\n }\n \n const char *get_git_work_tree(void)\n-- \n1.8.2.13.g0f18d3c\n"},{"id":"212324","messageId":"20130326201208.GB22522@sigill.intra.peff.net","threadId":"33283","inReplyTo":"20130326200851.GA22080@sigill.intra.peff.net","subject":"[DONOTAPPLY PATCH 2/3] setup: warn about implicit worktree with $GIT_DIR","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T20:12:08Z","receivedAt":"2013-03-26T20:12:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"It can be surprising to some users that pointing GIT_DIR to\na \".git\" directory does not use the working tree that\nsurrounds the .git directory, but rather uses the current\nworking directory as the working tree.\n\nGit has always worked this way, and for the most part it has\nnot been a big problem. However, given that one way of the\nuser finding this out is by having a destructive git command\nimpact an unexpected area of the filesystem, it would be\nnice to default to something less surprising and likely to\ncause problems (namely, having no working directory).\n\nThis breaks existing users of the feature, of course; they\ncan adapt by setting GIT_WORK_TREE explicitly to \".\", but\nthey need to be told to do so. Therefore we'll start with a\ndeprecation period and a warning to give them time to fix\ntheir scripts and workflows.\n\nSigned-off-by: Jeff King \n---\n setup.c | 21 ++++++++++++++++++++-\n t/t1510-repo-setup.sh | 8 ++++++--\n 2 files changed, 26 insertions(+), 3 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 01c5476..afc245f 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -437,6 +437,23 @@ const char *read_gitfile(const char *path)\n \treturn path;\n }\n \n+static const char warn_implicit_work_tree_msg[] =\n+N_(\"You have set GIT_DIR (or used --git-dir) without specifying\\n\"\n+ \"a working tree. In Git 2.0, the behavior will change from using current\\n\"\n+ \"working directory as the working tree to having no working tree at all.\\n\"\n+ \"If you wish to continue the current behavior, please set GIT_WORK_TREE\\n\"\n+ \"or core.worktree explicitly. See `git help git` for more details.\");\n+\n+static void warn_implicit_work_tree(void)\n+{\n+\tstatic int warn_once;\n+\n+\tif (warn_once++)\n+\t\treturn;\n+\n+\twarning(\"%s\", _(warn_implicit_work_tree_msg));\n+}\n+\n static const char *setup_explicit_git_dir(const char *gitdirenv,\n \t\t\t\t\t char *cwd, int len,\n \t\t\t\t\t int *nongit_ok)\n@@ -503,8 +520,10 @@ static const char *setup_explicit_git_dir(const char *gitdirenv,\n \t\tfree(gitfile);\n \t\treturn NULL;\n \t}\n-\telse /* #2, #10 */\n+\telse { /* #2, #10 */\n+\t\twarn_implicit_work_tree();\n \t\tset_git_work_tree(\".\");\n+\t}\n \n \t/* set_git_work_tree() must have been called by now */\n \tworktree = get_git_work_tree();\ndiff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh\nindex cf2ee78..0910de1 100755\n--- a/t/t1510-repo-setup.sh\n+++ b/t/t1510-repo-setup.sh\n@@ -243,7 +243,9 @@ test_expect_success '#2: worktree defaults to cwd with explicit GIT_DIR' '\n test_expect_success '#2: worktree defaults to cwd with explicit GIT_DIR' '\n \ttry_repo 2 unset \"$here/2/.git\" unset \"\" unset \\\n \t\t\"$here/2/.git\" \"$here/2\" \"$here/2\" \"(null)\" \\\n-\t\t\"$here/2/.git\" \"$here/2/sub\" \"$here/2/sub\" \"(null)\"\n+\t\t\"$here/2/.git\" \"$here/2/sub\" \"$here/2/sub\" \"(null)\" \\\n+\t\t2>message &&\n+\ttest_i18ngrep \"warning:.*GIT_DIR\" message\n '\n \n test_expect_success '#2b: relative GIT_DIR' '\n@@ -378,7 +380,9 @@ test_expect_success '#10: GIT_DIR can point to gitfile' '\n test_expect_success '#10: GIT_DIR can point to gitfile' '\n \ttry_repo 10 unset \"$here/10/.git\" unset gitfile unset \\\n \t\t\"$here/10.git\" \"$here/10\" \"$here/10\" \"(null)\" \\\n-\t\t\"$here/10.git\" \"$here/10/sub\" \"$here/10/sub\" \"(null)\"\n+\t\t\"$here/10.git\" \"$here/10/sub\" \"$here/10/sub\" \"(null)\" \\\n+\t\t2>message &&\n+\ttest_i18ngrep \"warning:.*GIT_DIR\" message\n '\n \n test_expect_success '#10b: relative GIT_DIR can point to gitfile' '\n-- \n1.8.2.13.g0f18d3c\n"},{"id":"212325","messageId":"20130326201333.GC22522@sigill.intra.peff.net","threadId":"33283","inReplyTo":"20130326200851.GA22080@sigill.intra.peff.net","subject":"[DONOTAPPLY PATCH 3/3] setup: treat GIT_DIR without GIT_WORK_TREE as a bare repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T20:13:33Z","receivedAt":"2013-03-26T20:13:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Follow-through on the deprecation warning added by the last\ncommit.\n\nWe can drop all of the IMPLICIT_WORK_TREE code now, since\nwe default to that case.\n\nSigned-off-by: Jeff King \n---\nThis would obviously come much later than patch 2, in Git 2.0 or\nwhatever.\n\nBut in case anyone did not read the discussion leading up to this\nseries, this breaks many tests. It's not meant for application, but\nmerely to look at what kinds of breakage we could see if we followed\nthis path.\n\n cache.h | 12 ------------\n environment.c | 1 -\n git.c | 1 -\n setup.c | 26 +-------------------------\n t/t1510-repo-setup.sh | 24 ++++++++++--------------\n 5 files changed, 11 insertions(+), 53 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex c1fe67f..3c6b677 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -366,18 +366,6 @@ static inline enum object_type object_type(unsigned int mode)\n #define GIT_NOTES_REWRITE_MODE_ENVIRONMENT \"GIT_NOTES_REWRITE_MODE\"\n \n /*\n- * This environment variable is expected to contain a boolean indicating\n- * whether we should or should not treat:\n- *\n- * GIT_DIR=foo.git git ...\n- *\n- * as if GIT_WORK_TREE=. was given. It's not expected that users will make use\n- * of this, but we use it internally to communicate to sub-processes that we\n- * are in a bare repo. If not set, defaults to true.\n- */\n-#define GIT_IMPLICIT_WORK_TREE_ENVIRONMENT \"GIT_IMPLICIT_WORK_TREE\"\n-\n-/*\n * Repository-local GIT_* environment variables; these will be cleared\n * when git spawns a sub-process that runs inside another repository.\n * The array is NULL-terminated, which makes it easy to pass in the \"env\"\ndiff --git a/environment.c b/environment.c\nindex be2e509..255e277 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -85,7 +85,6 @@ const char * const local_repo_env[] = {\n \tDB_ENVIRONMENT,\n \tGIT_DIR_ENVIRONMENT,\n \tGIT_WORK_TREE_ENVIRONMENT,\n-\tGIT_IMPLICIT_WORK_TREE_ENVIRONMENT,\n \tGRAFT_ENVIRONMENT,\n \tINDEX_ENVIRONMENT,\n \tNO_REPLACE_OBJECTS_ENVIRONMENT,\ndiff --git a/git.c b/git.c\nindex 0ffea57..d33f9b3 100644\n--- a/git.c\n+++ b/git.c\n@@ -125,7 +125,6 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t\tstatic char git_dir[PATH_MAX+1];\n \t\t\tis_bare_repository_cfg = 1;\n \t\t\tsetenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);\n-\t\t\tsetenv(GIT_IMPLICIT_WORK_TREE_ENVIRONMENT, \"0\", 1);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n \t\t} else if (!strcmp(cmd, \"-c\")) {\ndiff --git a/setup.c b/setup.c\nindex afc245f..319dbb5 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -437,23 +437,6 @@ const char *read_gitfile(const char *path)\n \treturn path;\n }\n \n-static const char warn_implicit_work_tree_msg[] =\n-N_(\"You have set GIT_DIR (or used --git-dir) without specifying\\n\"\n- \"a working tree. In Git 2.0, the behavior will change from using current\\n\"\n- \"working directory as the working tree to having no working tree at all.\\n\"\n- \"If you wish to continue the current behavior, please set GIT_WORK_TREE\\n\"\n- \"or core.worktree explicitly. See `git help git` for more details.\");\n-\n-static void warn_implicit_work_tree(void)\n-{\n-\tstatic int warn_once;\n-\n-\tif (warn_once++)\n-\t\treturn;\n-\n-\twarning(\"%s\", _(warn_implicit_work_tree_msg));\n-}\n-\n static const char *setup_explicit_git_dir(const char *gitdirenv,\n \t\t\t\t\t char *cwd, int len,\n \t\t\t\t\t int *nongit_ok)\n@@ -514,16 +497,11 @@ static const char *setup_explicit_git_dir(const char *gitdirenv,\n \t\t\tset_git_work_tree(core_worktree);\n \t\t}\n \t}\n-\telse if (!git_env_bool(GIT_IMPLICIT_WORK_TREE_ENVIRONMENT, 1)) {\n-\t\t/* #16d */\n+\telse { /* #2, #10, #16d */\n \t\tset_git_dir(gitdirenv);\n \t\tfree(gitfile);\n \t\treturn NULL;\n \t}\n-\telse { /* #2, #10 */\n-\t\twarn_implicit_work_tree();\n-\t\tset_git_work_tree(\".\");\n-\t}\n \n \t/* set_git_work_tree() must have been called by now */\n \tworktree = get_git_work_tree();\n@@ -600,8 +578,6 @@ static const char *setup_bare_git_dir(char *cwd, int offset, int len, int *nongi\n \tif (check_repository_format_gently(\".\", nongit_ok))\n \t\treturn NULL;\n \n-\tsetenv(GIT_IMPLICIT_WORK_TREE_ENVIRONMENT, \"0\", 1);\n-\n \t/* --work-tree is set without --git-dir; use discovered one */\n \tif (getenv(GIT_WORK_TREE_ENVIRONMENT) || git_work_tree_cfg) {\n \t\tconst char *gitdir;\ndiff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh\nindex 0910de1..7db4b3f 100755\n--- a/t/t1510-repo-setup.sh\n+++ b/t/t1510-repo-setup.sh\n@@ -28,7 +28,7 @@ A few rules for repo setup:\n 7. Effective core.worktree conflicts with core.bare\n \n 8. If GIT_DIR is set but neither worktree nor bare setting is given,\n- original cwd becomes worktree.\n+ we treat the repository as bare.\n \n 9. If .git discovery is done inside a repo, the repo becomes a bare\n repo. .git discovery is performed if GIT_DIR is not set.\n@@ -240,18 +240,16 @@ test_expect_success '#2b: relative GIT_DIR' '\n \t! test -s message\n '\n \n-test_expect_success '#2: worktree defaults to cwd with explicit GIT_DIR' '\n+test_expect_success '#2: worktree defaults to bare with explicit GIT_DIR' '\n \ttry_repo 2 unset \"$here/2/.git\" unset \"\" unset \\\n-\t\t\"$here/2/.git\" \"$here/2\" \"$here/2\" \"(null)\" \\\n-\t\t\"$here/2/.git\" \"$here/2/sub\" \"$here/2/sub\" \"(null)\" \\\n-\t\t2>message &&\n-\ttest_i18ngrep \"warning:.*GIT_DIR\" message\n+\t\t\"$here/2/.git\" \"(null)\" \"$here/2\" \"(null)\" \\\n+\t\t\"$here/2/.git\" \"(null)\" \"$here/2/sub\" \"(null)\"\n '\n \n test_expect_success '#2b: relative GIT_DIR' '\n \ttry_repo 2b unset \".git\" unset \"\" unset \\\n-\t\t\".git\" \"$here/2b\" \"$here/2b\" \"(null)\" \\\n-\t\t\"../.git\" \"$here/2b/sub\" \"$here/2b/sub\" \"(null)\"\n+\t\t\".git\" \"(null)\" \"$here/2b\" \"(null)\" \\\n+\t\t\"../.git\" \"(null)\" \"$here/2b/sub\" \"(null)\"\n '\n \n test_expect_success '#3: setup' '\n@@ -379,16 +377,14 @@ test_expect_success '#10b: relative GIT_DIR can point to gitfile' '\n \n test_expect_success '#10: GIT_DIR can point to gitfile' '\n \ttry_repo 10 unset \"$here/10/.git\" unset gitfile unset \\\n-\t\t\"$here/10.git\" \"$here/10\" \"$here/10\" \"(null)\" \\\n-\t\t\"$here/10.git\" \"$here/10/sub\" \"$here/10/sub\" \"(null)\" \\\n-\t\t2>message &&\n-\ttest_i18ngrep \"warning:.*GIT_DIR\" message\n+\t\t\"$here/10.git\" \"(null)\" \"$here/10\" \"(null)\" \\\n+\t\t\"$here/10.git\" \"(null)\" \"$here/10/sub\" \"(null)\"\n '\n \n test_expect_success '#10b: relative GIT_DIR can point to gitfile' '\n \ttry_repo 10b unset .git unset gitfile unset \\\n-\t\t\"$here/10b.git\" \"$here/10b\" \"$here/10b\" \"(null)\" \\\n-\t\t\"$here/10b.git\" \"$here/10b/sub\" \"$here/10b/sub\" \"(null)\"\n+\t\t\"$here/10b.git\" \"(null)\" \"$here/10b\" \"(null)\" \\\n+\t\t\"$here/10b.git\" \"(null)\" \"$here/10b/sub\" \"(null)\"\n '\n \n # case #11: GIT_WORK_TREE works, gitfile case.\n-- \n1.8.2.13.g0f18d3c\n"},{"id":"212326","messageId":"20130326201643.GK1414@google.com","threadId":"33283","inReplyTo":"20130326201140.GA22522@sigill.intra.peff.net","subject":"Re: [DONOTAPPLY PATCH 1/3] environment: set GIT_WORK_TREE when we figure out work tree","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-26T20:16:43Z","receivedAt":"2013-03-26T20:16:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> --- a/environment.c\n> +++ b/environment.c\n> @@ -194,6 +194,7 @@ void set_git_work_tree(const char *new_work_tree)\n> \t}\n> \tgit_work_tree_initialized = 1;\n> \twork_tree = xstrdup(real_path(new_work_tree));\n> +\tsetenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);\n> }\n\nThere's no rush, but I think this is a good change. It makes the rest\nof the codebase more resilient to running commands from a subdir of\nthe top level of the worktree.\n"},{"id":"212327","messageId":"20130326202142.GL1414@google.com","threadId":"33283","inReplyTo":"20130326201208.GB22522@sigill.intra.peff.net","subject":"Re: [DONOTAPPLY PATCH 2/3] setup: warn about implicit worktree with $GIT_DIR","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-26T20:21:42Z","receivedAt":"2013-03-26T20:21:42Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -437,6 +437,23 @@ const char *read_gitfile(const char *path)\n> \treturn path;\n> }\n> \n> +static const char warn_implicit_work_tree_msg[] =\n> +N_(\"You have set GIT_DIR (or used --git-dir) without specifying\\n\"\n> + \"a working tree. In Git 2.0, the behavior will change\n\nPlease no. I don't want git 2.0 to be delayed forever.\n\nIf we want this warning, would something like the following do?\n\n\twarning: You have set GIT_DIR without setting GIT_WORK_TREE\n\thint: In this case, GIT_WORK_TREE defaults to '.'\n\thint: To suppress this message, set GIT_WORK_TREE='.'\n\nThanks,\nJonathan\n"},{"id":"212328","messageId":"20130326202722.GA22769@sigill.intra.peff.net","threadId":"33283","inReplyTo":"20130326202142.GL1414@google.com","subject":"Re: [DONOTAPPLY PATCH 2/3] setup: warn about implicit worktree with $GIT_DIR","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-26T20:27:22Z","receivedAt":"2013-03-26T20:27:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 26, 2013 at 01:21:42PM -0700, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> \n> > --- a/setup.c\n> > +++ b/setup.c\n> > @@ -437,6 +437,23 @@ const char *read_gitfile(const char *path)\n> > \treturn path;\n> > }\n> > \n> > +static const char warn_implicit_work_tree_msg[] =\n> > +N_(\"You have set GIT_DIR (or used --git-dir) without specifying\\n\"\n> > + \"a working tree. In Git 2.0, the behavior will change\n> \n> Please no. I don't want git 2.0 to be delayed forever.\n\nPlease replace \"2.0\" with some future version, then. I just made up the\nnumber. But...\n\n> If we want this warning, would something like the following do?\n> \n> \twarning: You have set GIT_DIR without setting GIT_WORK_TREE\n> \thint: In this case, GIT_WORK_TREE defaults to '.'\n> \thint: To suppress this message, set GIT_WORK_TREE='.'\n\nThat can help by teaching people how GIT_DIR behaves in general. But the\nwarning and hint will be small consolation to somebody who runs\n\"GIT_DIR=foo.git git clean -f\" and sees it for the first time.\n\nIf you want to argue that people would see the warning in earlier runs\nof git, I can kind of buy that. Although the incident that triggered\nthis discussion probably wouldn't have (I would usually start a\ngit-clean session with \"git clean\" without \"-f\" or \"git status\", either\nof which would have done equally well as this warning to notify the user\nwhat was going on).\n\nLike I said earlier, though, I'm not really sure this is the direction\nwe want to go. This series is more about seeing what the fallouts are. I\nprobably shouldn't have included this middle patch at all, because the\ninteresting thing is what happens when we do turn it off.\n\n-Peff\n"},{"id":"212329","messageId":"20130326203523.GM1414@google.com","threadId":"33283","inReplyTo":"20130326202722.GA22769@sigill.intra.peff.net","subject":"Re: [DONOTAPPLY PATCH 2/3] setup: warn about implicit worktree with $GIT_DIR","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-26T20:35:23Z","receivedAt":"2013-03-26T20:35:23Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Tue, Mar 26, 2013 at 01:21:42PM -0700, Jonathan Nieder wrote:\n\n>> If we want this warning, would something like the following do?\n>> \n>> \twarning: You have set GIT_DIR without setting GIT_WORK_TREE\n>> \thint: In this case, GIT_WORK_TREE defaults to '.'\n>> \thint: To suppress this message, set GIT_WORK_TREE='.'\n>\n> That can help by teaching people how GIT_DIR behaves in general.\n\nYes, I think it would have helped in this case. If I understand\ncorrectly then for a while Richard was habitually setting GIT_DIR to\nmean \"act on this repository\" and thought the worktree was\nautomatically being set to the containing directory.\n\nI think patch 3 is a bad direction to go because there will always be\nold scripts that follow what used to be the recommended way to use\nGIT_DIR. In the long term a warning like this that doesn't break them\n(or a fatal error that at least doesn't confuse them) might be a good\nway to go.\n\nThanks for your thoughtful work, as always.\n\nJonathan\n"},{"id":"212343","messageId":"460E50A0F7A14FA796D6D74E25DA78F3@PhilipOakley","threadId":"33283","inReplyTo":"20130326094844.GA32583@duynguyen-vnpc.dek-tpc.internal","subject":"Re: git ate my home directory :-(","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-03-26T21:40:57Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Duy Nguyen\" \nSent: Tuesday, March 26, 2013 9:48 AM\n> On Tue, Mar 26, 2013 at 08:02:30AM -0000, Philip Oakley wrote:\n>> >> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when\n>> >> GIT_DIR is explicitly set.\n>> >\n>> > And it *WILL* be that way til the end of time. Unless you are at\n>> > the top level of your working tree, you are supposed to tell where\n>> > the top level is with GIT_WORK_TREE when you use GIT_DIR. Always.\n>>\n>> Should this important warning be part of the git(1) documentation on\n>> the\n>> environment variables (and possibly other places) given the\n>> consequences\n>> of this case? It wasn't something I'd appreciated from a simple\n>> reading.\n>\n> Something like this, maybe?\n>\n> -- 8< --\n> Subject: [PATCH] git.txt: document the implicit working tree setting\n> with GIT_DIR\n>\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Documentation/git.txt | 2 ++\n> 1 file changed, 2 insertions(+)\n>\n> diff --git a/Documentation/git.txt b/Documentation/git.txt\n> index 7efaa59..ce55abf 100644\n> --- a/Documentation/git.txt\n> +++ b/Documentation/git.txt\n> @@ -671,6 +671,8 @@ Git so take care if using Cogito etc.\n> specifies a path to use instead of the default `.git`\n> for the base of the repository.\n> The '--git-dir' command-line option also sets this value.\n> + If neither GIT_WORK_TREE nor '--work-tree' is set, the\n> + current directory will become the working tree.\n\nI didn't feel this conveyed the Dire Warning effect that would be needed\nto avoid the original misunderstanding.\n\nIt is easy to miss some of the potential consequences when other\npriorities are pressing.\n\nAs Junio wondered, perhaps rhetorically, in a later message \"Why do\nthese people set GIT_DIR without setting GIT_WORK_TREE in the first\nplace?\"\n\nPerhaps\n\"If the GIT_DIR environment variable is set then it specifies a path to\nuse instead of the default `.git` for the base of the repository. Note\nthat the current directory `.` will be used as the working\nGIT_WORK_TREE, if not set elsewhere. The --git-dir command-line\noption also sets the GIT_DIR environment variable.\"\n\n\n>\n> 'GIT_WORK_TREE'::\n> Set the path to the working tree. The value will not be\n> -- \n> 1.8.2.82.gc24b958\n> -- 8< --\n> --\nPhilip \n"},{"id":"212369","messageId":"vpq38vh1c8z.fsf@grenoble-inp.fr","threadId":"33283","inReplyTo":"20130326202722.GA22769@sigill.intra.peff.net","subject":"Re: [DONOTAPPLY PATCH 2/3] setup: warn about implicit worktree with $GIT_DIR","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-03-27T08:24:28Z","receivedAt":"2013-03-27T08:24:28Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> I probably shouldn't have included this middle patch at all, because\n> the interesting thing is what happens when we do turn it off.\n\nActually, I think the warning is the most important part. With the\nwarning enabled, people should notice they are doing something\npotentially wrong and dangerous, so the warning essentially fixes the\nissue in the short term.\n\nI also think that changing the default behavior later makes sense (but I\nagree that replacing \"in Git 2.0\" with \"in a future version of Git\" is\nbetter, there's no urgency for this change and people start looking\nforward 2.0).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"212373","messageId":"CACsJy8C9NM9BJHAftjWFby5EG7Yx3ofR7W3zQC9-KBgmpcWn2A@mail.gmail.com","threadId":"33283","inReplyTo":"20130326150428.GA3847@sigill.intra.peff.net","subject":"Re: git ate my home directory :-(","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-03-27T13:05:07Z","receivedAt":"2013-03-27T13:05:07Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 26, 2013 at 10:04 PM, Jeff King wrote:\n>> specifies a path to use instead of the default `.git`\n>> for the base of the repository.\n>> The '--git-dir' command-line option also sets this value.\n>> + If neither GIT_WORK_TREE nor '--work-tree' is set, the\n>> + current directory will become the working tree.\n>\n> I think this is a good thing to mention, but a few nits:\n>\n> 1. core.worktree is another way of setting it\n>\n> 2. This can also be overridden by --bare (at least in \"next\").\n>\n> 3. I think having core.bare set will also override this\n\nYeah, I looked back at t1510 and gave up. I think it's still true:\n\n-- 8< --\nA few rules for repo setup:\n\n1. GIT_DIR is relative to user's cwd. --git-dir is equivalent to\n GIT_DIR.\n\n2. .git file is relative to parent directory. .git file is basically\n symlink in disguise. The directory where .git file points to will\n become new git_dir.\n\n3. core.worktree is relative to git_dir.\n\n4. GIT_WORK_TREE is relative to user's cwd. --work-tree is\n equivalent to GIT_WORK_TREE.\n\n5. GIT_WORK_TREE/core.worktree was originally meant to work only if\n GIT_DIR is set, but earlier git didn't enforce it, and some scripts\n depend on the implementation that happened to first discover .git by\n going up from the users $cwd and then using the specified working tree\n that may or may not have any relation to where .git was found in. This\n historical behaviour must be kept.\n\n6. Effective GIT_WORK_TREE overrides core.worktree and core.bare\n\n7. Effective core.worktree conflicts with core.bare\n\n8. If GIT_DIR is set but neither worktree nor bare setting is given,\n original cwd becomes worktree.\n-- 8< --\n-- \nDuy\n"}]}