{"thread":{"id":"29055","subject":"BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","startedAt":"2011-11-30T17:43:08Z","lastAt":"2011-12-01T14:30:16Z","messageCount":7,"participants":["John Twilley","Carlos Martín Nieto","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180159","messageId":"CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com","threadId":"29055","inReplyTo":null,"subject":"BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"John Twilley","fromEmail":"mathuin@gmail.com","sentAt":"2011-11-30T17:43:08Z","receivedAt":"2011-11-30T17:43:08Z","isPatch":false,"sender":{"key":"mathuin@gmail.com","avatar":null},"body":"Today someone asked me if there was a way to run git against a\ndirectory other than the current directory.  I looked at the output of\n--help and ran this:\n\n$ git --work-tree blah status\n\nI got the following output:\n\nfatal: Not a git repository (or any parent up to mount parent /home)\nStopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n\nI mistakenly thought the error message meant that blah was not a git\nrepository.  What it meant was that there was no .git in the current\ndirectory or any parent directory up to /home.\n\nThis command worked as expected:\n\n$ git --work-tree blah --git-dir blah/.git status\n\nThe documentation is somewhat fuzzy about what constitutes a git\nrepository.  The gittutorial describes the git repository as .git when\ntalking about \"git init\" while the Git User's Manual describes the git\nrepository as the working tree and the special top-level directory\nnamed .git when talking about \"git clone\".\n\nIt's clear (to me at least) that --work-tree should be used to\nidentify the root of the working tree when not inside the working\ntree.  I expected that the git directory would be automatically set to\n.git in the root of the working tree, as that would match the\ndocumentation.  Instead, the current directory and its parents were\nchecked -- which could provide dangerously misleading information to\nthe user.\n\nI think that one of two things should be done:  either the --git-dir\ndefault should be changed when the --work-tree option is set, or the\nerror message cited above should be changed to explicitly identify the\ndirectory being tested as a potential git repository.  I personally\nbelieve the first option is superior because it fulfills the\nexpectations of average users (folks who read git's documentation\ninstead of its source code) while permitting flexibility to those who\nwish to refer to the current directory or some other directory for\ntheir --git-dir value.  If the current behavior is somehow not a bug\nbut instead a critical and significant feature which if changed would\ncause more harm than good, please consider the second option.\n\nJack.\n--\nmathuin at gmail dot com\n"},{"id":"180161","messageId":"20111130182230.GC12096@centaur.lab.cmartin.tk","threadId":"29055","inReplyTo":"CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-11-30T18:22:30Z","receivedAt":"2011-11-30T18:22:30Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:\n> Today someone asked me if there was a way to run git against a\n> directory other than the current directory.  I looked at the output of\n> --help and ran this:\n> \n> $ git --work-tree blah status\n> \n> I got the following output:\n> \n> fatal: Not a git repository (or any parent up to mount parent /home)\n> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n> \n> I mistakenly thought the error message meant that blah was not a git\n> repository.  What it meant was that there was no .git in the current\n> directory or any parent directory up to /home.\n\nYes, git looks at the current directory and .git/ to see if there's a\ngit repository there. This is what happens unless you tell git to look\nfor it somewhere else.\n\n> \n> This command worked as expected:\n> \n> $ git --work-tree blah --git-dir blah/.git status\n> \n> The documentation is somewhat fuzzy about what constitutes a git\n> repository.  The gittutorial describes the git repository as .git when\n> talking about \"git init\" while the Git User's Manual describes the git\n> repository as the working tree and the special top-level directory\n> named .git when talking about \"git clone\".\n\nA git repository is what's under .git/ (or in foo.git/ for bare\nrepos). Non-bare repositories have a working tree associated with\nthem, which by default lives just above the repository, because it'd\nbe silly to have it somewhere else by default. Often you can think of\nboth as the repository, as they're both. When you tell git to look for\nthe worktree somewhere else, you're only overriding that particular\nvariable, as git expects to be run from the repository (or just above,\nin the worktree).\n\n> \n> It's clear (to me at least) that --work-tree should be used to\n> identify the root of the working tree when not inside the working\n> tree.  I expected that the git directory would be automatically set to\n> .git in the root of the working tree, as that would match the\n> documentation.  Instead, the current directory and its parents were\n> checked -- which could provide dangerously misleading information to\n> the user.\n\nWhat part of the documentation exactly? --work-tree tells git to look\nfor the working tree somewhere else. This option exists in order to\nsupport a multiple-workdir workflow.\n\n> \n> I think that one of two things should be done:  either the --git-dir\n> default should be changed when the --work-tree option is set, or the\n> error message cited above should be changed to explicitly identify the\n> directory being tested as a potential git repository.  I personally\n\nGit does tell you explicitly, but only when you specify a gitdir (via\nGIT_DIR or --git-dir), otherwise it looks at the current directory.\n\n> believe the first option is superior because it fulfills the\n> expectations of average users (folks who read git's documentation\n> instead of its source code) while permitting flexibility to those who\n\nIt's not likely that it will get changed because that would break\nbackwards-compatability in a very big way. If your concern is for\n\"average user\", she shouldn't be using that option, but changing to\nthat directory instead. If you want your working tree to be ./foo/ and\nyour gitdir to be ./foo/.git, why don't you just cd to ./foo/?\n\n> wish to refer to the current directory or some other directory for\n> their --git-dir value.  If the current behavior is somehow not a bug\n> but instead a critical and significant feature which if changed would\n> cause more harm than good, please consider the second option.\n\nYou get two different messages depending on how git is looking for the\nrepository. The message you mentioned gets printed when git tries to\nfind it automatically. A \"fatal: Not a git repository: '/tmp'\" gets\nprinted if you've told git to look for it in a specific place. The\ninformation is already there, though I guess you do have to know about\nthe difference. Adding the current directory to the \"default\" message\nprobably wouldn't hurt, as it's unlikely that a script is parsing\nthat, and might be useful.\n\n   cmn\n"},{"id":"180165","messageId":"CAEUMa-fhqS-dJUePznZrEsKVSMDiAs=-JX93XTXZEm71Oix-1Q@mail.gmail.com","threadId":"29055","inReplyTo":"20111130182230.GC12096@centaur.lab.cmartin.tk","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"John Twilley","fromEmail":"mathuin@gmail.com","sentAt":"2011-11-30T19:13:20Z","receivedAt":"2011-11-30T19:13:20Z","isPatch":false,"sender":{"key":"mathuin@gmail.com","avatar":null},"body":"On Wed, Nov 30, 2011 at 10:22, Carlos Martín Nieto <cmn@elego.de> wrote:\n> On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:\n>> Today someone asked me if there was a way to run git against a\n>> directory other than the current directory.  I looked at the output of\n>> --help and ran this:\n>>\n>> $ git --work-tree blah status\n>>\n>> I got the following output:\n>>\n>> fatal: Not a git repository (or any parent up to mount parent /home)\n>> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n>>\n>> I mistakenly thought the error message meant that blah was not a git\n>> repository.  What it meant was that there was no .git in the current\n>> directory or any parent directory up to /home.\n>\n> Yes, git looks at the current directory and .git/ to see if there's a\n> git repository there. This is what happens unless you tell git to look\n> for it somewhere else.\n\nThis makes perfect sense, because nearly every time I run git\ncommands, I am somewhere within the working tree.  The point of my\npost was that I was using --work-tree to tell git to look for the git\nrepository somewhere else (the root of the specified working tree)\nwhich is not what git expected.\n\n>> This command worked as expected:\n>>\n>> $ git --work-tree blah --git-dir blah/.git status\n>>\n>> The documentation is somewhat fuzzy about what constitutes a git\n>> repository.  The gittutorial describes the git repository as .git when\n>> talking about \"git init\" while the Git User's Manual describes the git\n>> repository as the working tree and the special top-level directory\n>> named .git when talking about \"git clone\".\n>\n> A git repository is what's under .git/ (or in foo.git/ for bare\n> repos). Non-bare repositories have a working tree associated with\n> them, which by default lives just above the repository, because it'd\n> be silly to have it somewhere else by default. Often you can think of\n> both as the repository, as they're both. When you tell git to look for\n> the worktree somewhere else, you're only overriding that particular\n> variable, as git expects to be run from the repository (or just above,\n> in the worktree).\n\nAnd it's exactly this issue -- that sometimes the repository is just\nthe git directory, and sometimes the repository is the working tree\nwhich contains the git directory at its root -- that caused the\nconfusion and unexpected behavior.  If I were to use a bare repository\ndirectly (something I've never done), I guess I might use --git-dir\nsince the repository may not be named .git but instead something like\nproj.git.  When I accessed a repository from outside its working tree,\nI expected --work-tree to cover the whole shebang.  Obviously this\ndiscussion is exposing my relatively limited experience with git, but\nthese assumptions do not seem unreasonable on their face.\n\n>> It's clear (to me at least) that --work-tree should be used to\n>> identify the root of the working tree when not inside the working\n>> tree.  I expected that the git directory would be automatically set to\n>> .git in the root of the working tree, as that would match the\n>> documentation.  Instead, the current directory and its parents were\n>> checked -- which could provide dangerously misleading information to\n>> the user.\n>\n> What part of the documentation exactly? --work-tree tells git to look\n> for the working tree somewhere else. This option exists in order to\n> support a multiple-workdir workflow.\n\nWhat you mention above was what I was thinking about when I mentioned\nthe possibility of this being a critical and significant feature.  If\nit is important to support a workflow with one git directory and\nmultiple working trees, and that case is more common/important than\nthe one I experienced, then changing the behavior of --git-dir is\nobviously not the right thing to do.\n\n>> I think that one of two things should be done:  either the --git-dir\n>> default should be changed when the --work-tree option is set, or the\n>> error message cited above should be changed to explicitly identify the\n>> directory being tested as a potential git repository.  I personally\n>\n> Git does tell you explicitly, but only when you specify a gitdir (via\n> GIT_DIR or --git-dir), otherwise it looks at the current directory.\n\nThis is misleading if you don't know that the specification of a\nworking tree does not also implicitly specify a git directory.\nWhether that lack of knowledge is the user's problem or the\nsoftware/documentation's problem is a separate question.\n\n>> believe the first option is superior because it fulfills the\n>> expectations of average users (folks who read git's documentation\n>> instead of its source code) while permitting flexibility to those who\n>\n> It's not likely that it will get changed because that would break\n> backwards-compatability in a very big way. If your concern is for\n> \"average user\", she shouldn't be using that option, but changing to\n> that directory instead. If you want your working tree to be ./foo/ and\n> your gitdir to be ./foo/.git, why don't you just cd to ./foo/?\n\nFrom that perspective, why have --work-tree at all?  Without that\noption, either the git directory is in the root of your current\nworking tree, or it's not -- in which case --git-dir is all you need.\nIf you're going to keep the option, it's helpful to provide the\ndiagnostic output.  My suggestion would be more compelling if I could\nprovide a valid use case, but all I can come up with off the top of my\nhead are scripts and something like \"(cd $worktree && git status)\"\nwould probably work fine.\n\n>> wish to refer to the current directory or some other directory for\n>> their --git-dir value.  If the current behavior is somehow not a bug\n>> but instead a critical and significant feature which if changed would\n>> cause more harm than good, please consider the second option.\n>\n> You get two different messages depending on how git is looking for the\n> repository. The message you mentioned gets printed when git tries to\n> find it automatically. A \"fatal: Not a git repository: '/tmp'\" gets\n> printed if you've told git to look for it in a specific place. The\n> information is already there, though I guess you do have to know about\n> the difference. Adding the current directory to the \"default\" message\n> probably wouldn't hurt, as it's unlikely that a script is parsing\n> that, and might be useful.\n\nFewer scripts would be broken if the additional output is only\ndisplayed when --work-tree is used, but that might be too special-case\nfor this situation.\n\n>   cmn\n\nJack.\n--\nmathuin at gmail dot com\n"},{"id":"180167","messageId":"7vaa7dquva.fsf@alter.siamese.dyndns.org","threadId":"29055","inReplyTo":"CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-30T19:21:29Z","receivedAt":"2011-11-30T19:21:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Twilley <mathuin@gmail.com> writes:\n\n> Today someone asked me if there was a way to run git against a\n> directory other than the current directory.  I looked at the output of\n> --help and ran this:\n>\n> $ git --work-tree blah status\n>\n> I got the following output:\n>\n> fatal: Not a git repository (or any parent up to mount parent /home)\n\nYeah, that is a \"this a use case that we didn't even intend to support,\nand as a consequence we do a random thing\" bug.\n\nOriginally, when GIT_DIR is set (from the environment, and then later we\nadded \"git --git-dir=...\" as another way to do so), Git always used the\ncurrent directory as the top of the working tree. There was no mechanism\nfor the user to say \"No, I am not at the top level, but I am in a\nsubdirectory of the working tree. The top of working tree is there\".  That\nwas the use case GIT_WORK_TREE (from the environment, and then later we\nadded \"git --work-tree=...\" as another way to do so) was introduced\nfor.\n\nSo in that sense, it is an unsupported mode of operation and it is not\nsurprising at all if Git did any random and meaningless things if you used\nGIT_WORK_TREE without specifying GIT_DIR at all. In the same sense,\nstrictly speaking, setting GIT_WORK_TREE to somewhere that is not a parent\ndirectory of the current directory (even if you set GIT_DIR) is also an\nunsupported mode of operation.\n\nWhen GIT_DIR is not set, I think we still run the normal GIT_DIR discovery\nstarting from the current working directory, and when we do not find one,\nwe would error out, as you saw. I am sympathetic that your particular case\nmight have resulted in a more pleasant user experience if the GIT_DIR\ndiscovery started from the directory specified by GIT_WORK_TREE (i.e. the\nsubdirectory \"blah/.git\"), but I do not think this is likely to change, as\nI suspect that people and scripts are relying on the current behaviour to\nbe able to do something like this:\n\n    cd /pub/scm/git/git.git ;# this is a bare repository\n    mkdir /var/tmp/git\n    git --work-tree=/var/tmp/git checkout\n\nto have a temporary checkout, and changing the GIT_DIR discovery logic\nwill break them, i.e. they now have to do:\n\n    cd /pub/scm/git/git.git ;# this is a bare repository\n    mkdir /var/tmp/git\n    git --work-tree=/var/tmp/git --git-dir=$(pwd) checkout\n\nor something. Instead, what you wanted to do is already supported by:\n\n    (cd blah && git status)\n\nso nothing is lost.\n\nWe could reword this:\n\n> fatal: Not a git repository (or any parent up to mount parent /home)\n\nto \"fatal: /home/bar/baz (or any parent ...) is not a git repository\" to\nmention the current directory /home/bar/baz, but I am having a hard time\nconvincing myself that such a change is particularly good, because almost\nalways you know where you are (many people have it in their shell prompt).\nSuch a change makes the message longer to fit on a line without adding\nmuch value.\n"},{"id":"180168","messageId":"20111130194233.GD12096@centaur.lab.cmartin.tk","threadId":"29055","inReplyTo":"7vaa7dquva.fsf@alter.siamese.dyndns.org","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"Carlos Martín Nieto","fromEmail":"carlos@cmartin.tk","sentAt":"2011-11-30T19:42:33Z","receivedAt":"2011-11-30T19:42:33Z","isPatch":false,"sender":{"key":"carlos@cmartin.tk","avatar":"https://gravatar.com/avatar/956bfe8371004f2960febf266a6af789f60cdc01fbae48bb151ad4c9b532c3a2?d=mp&s=160"},"body":"On Wed, Nov 30, 2011 at 11:21:29AM -0800, Junio C Hamano wrote:\n> subdirectory \"blah/.git\"), but I do not think this is likely to change, as\n> I suspect that people and scripts are relying on the current behaviour to\n> be able to do something like this:\n> \n>     cd /pub/scm/git/git.git ;# this is a bare repository\n>     mkdir /var/tmp/git\n>     git --work-tree=/var/tmp/git checkout\n> \n\nThis is in fact the way that many (or from what I can see the most\npopular) tutorials for abusing git as a deployment system tell you to\nrun it (though more often than not setting GIT_WORKTREE in the\nenvironment).\n\n   cmn\n\n"},{"id":"180170","messageId":"7v1uspqqyy.fsf@alter.siamese.dyndns.org","threadId":"29055","inReplyTo":"20111130194233.GD12096@centaur.lab.cmartin.tk","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-30T20:45:41Z","receivedAt":"2011-11-30T20:45:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <carlos@cmartin.tk> writes:\n\n> On Wed, Nov 30, 2011 at 11:21:29AM -0800, Junio C Hamano wrote:\n>> subdirectory \"blah/.git\"), but I do not think this is likely to change, as\n>> I suspect that people and scripts are relying on the current behaviour to\n>> be able to do something like this:\n>> \n>>     cd /pub/scm/git/git.git ;# this is a bare repository\n>>     mkdir /var/tmp/git\n>>     git --work-tree=/var/tmp/git checkout\n>\n> This is in fact the way that many (or from what I can see the most\n> popular) tutorials for abusing git as a deployment system tell you to\n> run it (though more often than not setting GIT_WORKTREE in the\n> environment).\n\nHeh, *ab*using is a good description if they really mean to use it as a\ndeployment system. For one thing it won't do anything a proper deployment\nshould do if the target directory is not empty ;-)\n"},{"id":"180199","messageId":"20111201143016.GC2386@beez.lab.cmartin.tk","threadId":"29055","inReplyTo":"CAEUMa-fhqS-dJUePznZrEsKVSMDiAs=-JX93XTXZEm71Oix-1Q@mail.gmail.com","subject":"Re: BUG: \"--work-tree blah\" does not imply \"--git-dir blah/.git\" or fix misleading error message","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-12-01T14:30:16Z","receivedAt":"2011-12-01T14:30:16Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, Nov 30, 2011 at 11:13:20AM -0800, John Twilley wrote:\n> On Wed, Nov 30, 2011 at 10:22, Carlos Martín Nieto <cmn@elego.de> wrote:\n> > On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:\n> >> Today someone asked me if there was a way to run git against a\n> >> directory other than the current directory.  I looked at the output of\n> >> --help and ran this:\n> >>\n> >> $ git --work-tree blah status\n> >>\n> >> I got the following output:\n> >>\n> >> fatal: Not a git repository (or any parent up to mount parent /home)\n> >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).\n> >>\n> >> I mistakenly thought the error message meant that blah was not a git\n> >> repository.  What it meant was that there was no .git in the current\n> >> directory or any parent directory up to /home.\n> >\n> > Yes, git looks at the current directory and .git/ to see if there's a\n> > git repository there. This is what happens unless you tell git to look\n> > for it somewhere else.\n> \n> This makes perfect sense, because nearly every time I run git\n> commands, I am somewhere within the working tree.  The point of my\n> post was that I was using --work-tree to tell git to look for the git\n> repository somewhere else (the root of the specified working tree)\n> which is not what git expected.\n\nAnd as Junio said, git devs have never considered the case where you\nwant to run git from a directory, but have git look for the worktree +\nrepo in a different place. Since what you want to do is solved\ntrivially by cd'ing in a subshell \"(cd blah && git status)\" it's not\nsurprising that this hasn't come up.\n\n> \n> >> This command worked as expected:\n> >>\n> >> $ git --work-tree blah --git-dir blah/.git status\n> >>\n> >> The documentation is somewhat fuzzy about what constitutes a git\n> >> repository.  The gittutorial describes the git repository as .git when\n> >> talking about \"git init\" while the Git User's Manual describes the git\n> >> repository as the working tree and the special top-level directory\n> >> named .git when talking about \"git clone\".\n> >\n> > A git repository is what's under .git/ (or in foo.git/ for bare\n> > repos). Non-bare repositories have a working tree associated with\n> > them, which by default lives just above the repository, because it'd\n> > be silly to have it somewhere else by default. Often you can think of\n> > both as the repository, as they're both. When you tell git to look for\n> > the worktree somewhere else, you're only overriding that particular\n> > variable, as git expects to be run from the repository (or just above,\n> > in the worktree).\n> \n> And it's exactly this issue -- that sometimes the repository is just\n> the git directory, and sometimes the repository is the working tree\n> which contains the git directory at its root -- that caused the\n> confusion and unexpected behavior.  If I were to use a bare repository\n> directly (something I've never done), I guess I might use --git-dir\n> since the repository may not be named .git but instead something like\n> proj.git.  When I accessed a repository from outside its working tree,\n> I expected --work-tree to cover the whole shebang.  Obviously this\n> discussion is exposing my relatively limited experience with git, but\n> these assumptions do not seem unreasonable on their face.\n\nYou hardly ever need to use git directly on a bare repo, but when you\ndo, you can just it from inside the repo, but most of the time git\nexpects to be run from the place where the repo+worktree combination\nis to be found. Anything else is a low-level configuration and is just\nnot expected to be used by people who aren't familiar with git's usage\nof \"worktree\".\n\n> \n> >> It's clear (to me at least) that --work-tree should be used to\n> >> identify the root of the working tree when not inside the working\n> >> tree.  I expected that the git directory would be automatically set to\n> >> .git in the root of the working tree, as that would match the\n> >> documentation.  Instead, the current directory and its parents were\n> >> checked -- which could provide dangerously misleading information to\n> >> the user.\n> >\n> > What part of the documentation exactly? --work-tree tells git to look\n> > for the working tree somewhere else. This option exists in order to\n> > support a multiple-workdir workflow.\n> \n> What you mention above was what I was thinking about when I mentioned\n> the possibility of this being a critical and significant feature.  If\n> it is important to support a workflow with one git directory and\n> multiple working trees, and that case is more common/important than\n> the one I experienced, then changing the behavior of --git-dir is\n> obviously not the right thing to do.\n\nIt's not just about it being a critical feature. Yes it would break\nmany scripts, but what you want to do is meant to be done with a\nsubshell and I fail to see why git should go out of its way to support\nsuch a usercase.\n\n> \n> >> I think that one of two things should be done:  either the --git-dir\n> >> default should be changed when the --work-tree option is set, or the\n> >> error message cited above should be changed to explicitly identify the\n> >> directory being tested as a potential git repository.  I personally\n> >\n> > Git does tell you explicitly, but only when you specify a gitdir (via\n> > GIT_DIR or --git-dir), otherwise it looks at the current directory.\n> \n> This is misleading if you don't know that the specification of a\n> working tree does not also implicitly specify a git directory.\n> Whether that lack of knowledge is the user's problem or the\n> software/documentation's problem is a separate question.\n\nThe documentation now thankfully doesn't talk about working copy\nanymore, so it should be fairly consistent. The gitglossary definition\nof worktree should also explain what a worktree is.\n\n> \n> >> believe the first option is superior because it fulfills the\n> >> expectations of average users (folks who read git's documentation\n> >> instead of its source code) while permitting flexibility to those who\n> >\n> > It's not likely that it will get changed because that would break\n> > backwards-compatability in a very big way. If your concern is for\n> > \"average user\", she shouldn't be using that option, but changing to\n> > that directory instead. If you want your working tree to be ./foo/ and\n> > your gitdir to be ./foo/.git, why don't you just cd to ./foo/?\n> \n> From that perspective, why have --work-tree at all?  Without that\n> option, either the git directory is in the root of your current\n> working tree, or it's not -- in which case --git-dir is all you need.\n\nThe reason for --work-tree (and the earlier GIT_WORKTREE) is to allow\nyou to temporarily set the worktree somewhere else. It's meant to tell\ngit to pretend $PWD is something else.\n\n> If you're going to keep the option, it's helpful to provide the\n> diagnostic output.  My suggestion would be more compelling if I could\n> provide a valid use case, but all I can come up with off the top of my\n> head are scripts and something like \"(cd $worktree && git status)\"\n> would probably work fine.\n\nThis subshell method is exactly how everyone's always written this\nkind of thing, and the way that you're supposed to (and I don't mean\nfor git, I mean for any tool). Adding the option explicitly to git\nwould introduce an further potential source of bugs and is unnecessary.\n\n> \n> >> wish to refer to the current directory or some other directory\nfor\n> >> their --git-dir value.  If the current behavior is somehow not a bug\n> >> but instead a critical and significant feature which if changed would\n> >> cause more harm than good, please consider the second option.\n> >\n> > You get two different messages depending on how git is looking for the\n> > repository. The message you mentioned gets printed when git tries to\n> > find it automatically. A \"fatal: Not a git repository: '/tmp'\" gets\n> > printed if you've told git to look for it in a specific place. The\n> > information is already there, though I guess you do have to know about\n> > the difference. Adding the current directory to the \"default\" message\n> > probably wouldn't hurt, as it's unlikely that a script is parsing\n> > that, and might be useful.\n> \n> Fewer scripts would be broken if the additional output is only\n> displayed when --work-tree is used, but that might be too special-case\n> for this situation.\n\nThat would connect unrelated code, I doubt it's reasonable.\n\n   cmn\n"}]}