{"thread":{"id":"61322","subject":"Unexpected behavior with the rev-parse operation","startedAt":"2024-04-15T13:58:21Z","lastAt":"2024-05-01T04:55:56Z","messageCount":6,"participants":["Toru Okugawa","Eric Sunshine","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"492943","messageId":"CANHPH1-6mbWdt_FLsrDEB_XVb4r3yTYMLLPUyDrL6tmS7jZgqQ@mail.gmail.com","threadId":"61322","inReplyTo":null,"subject":"Unexpected behavior with the rev-parse operation","fromName":"Toru Okugawa","fromEmail":"castor.4bit@gmail.com","sentAt":"2024-04-15T13:58:09Z","receivedAt":"2024-04-15T13:58:21Z","isPatch":false,"sender":{"key":"castor.4bit@gmail.com","avatar":"https://gravatar.com/avatar/8ace42971ee27f54e429f97234431223f0bfa923fcc565ea1f17e8cf50809f47?d=mp&s=160"},"body":"Hi,\n\nI have encountered some unexpected behavior with the rev-parse operation.\n\n---\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n```\n$ mkdir -p /tmp/example\n$ cd $_\n$ ls -a\n.  ..\n\n$ git rev-parse --is-inside-work-tree\nfatal: not a git repository (or any of the parent directories): .git\n```\n\nWhat did you expect to happen? (Expected behavior)\n\nIf the current working directory is outside the work tree, the\ndocumentation says that `git rev-parse --is-inside-work-tree` will\noutput false.\nhttps://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt---is-inside-work-tree\n\n```\n$ git rev-parse --is-inside-work-tree\nfalse\n```\n\nWhat happened instead? (Actual behavior)\n\nIt will output `fatal: not a git repository (or any of the parent\ndirectories): .git` and exit with code 128. The `--is-inside-git-dir`\noption works the same way.\n\n```\n$ git rev-parse --is-inside-work-tree\nfatal: not a git repository (or any of the parent directories): .git\n```\n\n[System Info]\ngit version:\ngit version 2.44.0\ncpu: arm64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:53\nPDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 arm64\ncompiler info: clang: 15.0.0 (clang-1500.1.0.2.5)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /opt/homebrew/bin/zsh\n\n\nThanks\n"},{"id":"493556","messageId":"CAPig+cQ39Z+WjThqkxCKgOUfkZyB6PG-6RhHBYhinp-ZY4dxKA@mail.gmail.com","threadId":"61322","inReplyTo":"CANHPH1-6mbWdt_FLsrDEB_XVb4r3yTYMLLPUyDrL6tmS7jZgqQ@mail.gmail.com","subject":"Re: Unexpected behavior with the rev-parse operation","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-04-28T18:08:47Z","receivedAt":"2024-04-28T18:09:00Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:\n> I have encountered some unexpected behavior with the rev-parse operation.\n> ---\n> $ ls -a\n> .  ..\n> $ git rev-parse --is-inside-work-tree\n> fatal: not a git repository (or any of the parent directories): .git\n>\n> What did you expect to happen? (Expected behavior)\n>\n> If the current working directory is outside the work tree, the\n> documentation says that `git rev-parse --is-inside-work-tree` will\n> output false.\n> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt---is-inside-work-tree\n\nI think this is working as intended, but the documentation is lacking\nor misleading. With very few exceptions[1], `git rev-parse` expects to\nbe run either within a Git working tree or within a Git repository\n(i.e. the .git/ directory or a bare repository). Options such as\n--is-inside-work-tree, --is-bare-repository, etc. are meant to report\nupon aspects of the worktree or repository in which the command is\ninvoked.\n\nLooking at the source code for `git rev-parse`, it does appear that it\nhas explicit support for the case of checking whether or not the\ncurrent directory is a Git worktree or repository. The way to do that\nis to run `git rev-parse` without any arguments. However, even in that\ncase, it will print the \"fatal: not a git repository\" error. This\nmeans it is your responsibility, as a script writer, to suppress or\ncapture the error message (whichever is appropriate for your case).\nFor instance:\n\n    if test git rev-parse >/dev/null 2>&1\n    then\n        echo \"in a Git directory or repository\"\n    else\n        echo \"not in a Git directory or repository\"\n    fi\n\n[1]: --sh-quote, --parse-opt, --local-env-vars, --resolve-git-dir\n"},{"id":"493575","messageId":"xmqqedap2ijk.fsf_-_@gitster.g","threadId":"61322","inReplyTo":"CAPig+cQ39Z+WjThqkxCKgOUfkZyB6PG-6RhHBYhinp-ZY4dxKA@mail.gmail.com","subject":"Re* Unexpected behavior with the rev-parse operation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-28T23:07:11Z","receivedAt":"2024-04-28T23:07:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:\n>> I have encountered some unexpected behavior with the rev-parse operation.\n>> ---\n>> $ ls -a\n>> .  ..\n>> $ git rev-parse --is-inside-work-tree\n>> fatal: not a git repository (or any of the parent directories): .git\n>> ...\n> ... This\n> means it is your responsibility, as a script writer, to suppress or\n> capture the error message (whichever is appropriate for your case).\n> For instance:\n>\n>     if test git rev-parse >/dev/null 2>&1\n>     then\n>         echo \"in a Git directory or repository\"\n>     else\n>         echo \"not in a Git directory or repository\"\n>     fi\n\nAll true.  It may however need some documentation updates, though,\nsomething along this line, perhaps?\n\n Documentation/git-rev-parse.txt | 16 ++++++++++++++--\n 1 file changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git c/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt\nindex f9d5a35fa0..a62d798744 100644\n--- c/Documentation/git-rev-parse.txt\n+++ w/Documentation/git-rev-parse.txt\n@@ -18,8 +18,16 @@ Many Git porcelainish commands take a mixture of flags\n (i.e. parameters that begin with a dash '-') and parameters\n meant for the underlying 'git rev-list' command they use internally\n and flags and parameters for the other commands they use\n-downstream of 'git rev-list'.  This command is used to\n-distinguish between them.\n+downstream of 'git rev-list'.  One purpose of this command is to\n+allow calling programs to distinguish between them.\n+\n+There are a few other operation modes that have noting to do with\n+the above \"help parse command line options\" added to the command.\n+\n+Unless otherwise specified, most of the options and operation modes\n+require you to run this command inside a git repository or a working\n+tree that is under control of a git repository, and will give you a\n+fatal error otherwise.\n \n \n OPTIONS\n@@ -32,11 +40,15 @@ Each of these options must appear first on the command line.\n \n --parseopt::\n \tUse 'git rev-parse' in option parsing mode (see PARSEOPT section below).\n+\tThe command in this mode can be used outside a repository or\n+\ta working tree controlled by a repository.\n \n --sq-quote::\n \tUse 'git rev-parse' in shell quoting mode (see SQ-QUOTE\n \tsection below). In contrast to the `--sq` option below, this\n \tmode only does quoting. Nothing else is done to command input.\n+\tThe command in this mode can be used outside a repository or\n+\ta working tree controlled by a repository.\n \n Options for --parseopt\n ~~~~~~~~~~~~~~~~~~~~~~\n"},{"id":"493779","messageId":"CANHPH19FCWUAMZLFZEY+_+zv0KUkuVGNQS26WmEPjnPtjrK8KQ@mail.gmail.com","threadId":"61322","inReplyTo":"xmqqedap2ijk.fsf_-_@gitster.g","subject":"Re: Re* Unexpected behavior with the rev-parse operation","fromName":"Toru Okugawa","fromEmail":"castor.4bit@gmail.com","sentAt":"2024-04-30T14:26:04Z","receivedAt":"2024-04-30T14:26:16Z","isPatch":false,"sender":{"key":"castor.4bit@gmail.com","avatar":"https://gravatar.com/avatar/8ace42971ee27f54e429f97234431223f0bfa923fcc565ea1f17e8cf50809f47?d=mp&s=160"},"body":"On Mon, Apr 29, 2024 at 8:07 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Eric Sunshine <sunshine@sunshineco.com> writes:\n>\n> > On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:\n> >> I have encountered some unexpected behavior with the rev-parse operation.\n> >> ---\n> >> $ ls -a\n> >> .  ..\n> >> $ git rev-parse --is-inside-work-tree\n> >> fatal: not a git repository (or any of the parent directories): .git\n> >> ...\n> > ... This\n> > means it is your responsibility, as a script writer, to suppress or\n> > capture the error message (whichever is appropriate for your case).\n> > For instance:\n> >\n> >     if test git rev-parse >/dev/null 2>&1\n> >     then\n> >         echo \"in a Git directory or repository\"\n> >     else\n> >         echo \"not in a Git directory or repository\"\n> >     fi\n>\n> All true.  It may however need some documentation updates, though,\n> something along this line, perhaps?\n>\n>  Documentation/git-rev-parse.txt | 16 ++++++++++++++--\n>  1 file changed, 14 insertions(+), 2 deletions(-)\n>\n> diff --git c/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt\n> index f9d5a35fa0..a62d798744 100644\n> --- c/Documentation/git-rev-parse.txt\n> +++ w/Documentation/git-rev-parse.txt\n> @@ -18,8 +18,16 @@ Many Git porcelainish commands take a mixture of flags\n>  (i.e. parameters that begin with a dash '-') and parameters\n>  meant for the underlying 'git rev-list' command they use internally\n>  and flags and parameters for the other commands they use\n> -downstream of 'git rev-list'.  This command is used to\n> -distinguish between them.\n> +downstream of 'git rev-list'.  One purpose of this command is to\n> +allow calling programs to distinguish between them.\n> +\n> +There are a few other operation modes that have noting to do with\n> +the above \"help parse command line options\" added to the command.\n> +\n> +Unless otherwise specified, most of the options and operation modes\n> +require you to run this command inside a git repository or a working\n> +tree that is under control of a git repository, and will give you a\n> +fatal error otherwise.\n>\n>\n>  OPTIONS\n> @@ -32,11 +40,15 @@ Each of these options must appear first on the command line.\n>\n>  --parseopt::\n>         Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).\n> +       The command in this mode can be used outside a repository or\n> +       a working tree controlled by a repository.\n>\n>  --sq-quote::\n>         Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE\n>         section below). In contrast to the `--sq` option below, this\n>         mode only does quoting. Nothing else is done to command input.\n> +       The command in this mode can be used outside a repository or\n> +       a working tree controlled by a repository.\n>\n>  Options for --parseopt\n>  ~~~~~~~~~~~~~~~~~~~~~~\n\nThank you for your responses.\n\nI'm aware that `--is-inside-work-tree` is an option for `git\nrev-parse`, and I understand that it is normal for the command to\ngenerate an error when executed outside a Git repository. Indeed, I\nhave previously used the result of `git rev-parse >/dev/null 2>&1` to\ndetermine whether the directory is inside a Git repository or not.\n\nHowever, if determining the presence of a Git repository by checking\nfor errors is the appropriate approach, I'm interested in\nunderstanding the intended use of the `--is-inside-work-tree` option.\nI had thought it was meant to suppress errors in exceptional cases.\n"},{"id":"493805","messageId":"xmqqedamzo17.fsf@gitster.g","threadId":"61322","inReplyTo":"CANHPH19FCWUAMZLFZEY+_+zv0KUkuVGNQS26WmEPjnPtjrK8KQ@mail.gmail.com","subject":"Re: Re* Unexpected behavior with the rev-parse operation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-30T18:46:44Z","receivedAt":"2024-04-30T18:46:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Toru Okugawa <castor.4bit@gmail.com> writes:\n\n> However, if determining the presence of a Git repository by checking\n> for errors is the appropriate approach, I'm interested in\n> understanding the intended use of the `--is-inside-work-tree` option.\n> I had thought it was meant to suppress errors in exceptional cases.\n\n    $ rm -fr mine\n    $ git init mine ;# notice the lack of --bare\n    $ cd mine\n    $ git commit --allow-empty -m 'initial'\n    $ git rev-parse --is-inside-work-tree; echo $?\n    true\n    0\n    $ cd .git\n    $ git rev-parse --is-inside-work-tree; echo $?\n    false\n    0\n    $ cd ../..\n    $ git --bare init mine.bare ;# this time bare\n    $ cd mine.bare\n    false\n    0\n\nWhen you write a script that you might want to use as a part of a\nhook, for example, you may end up running it inside .git/ and it may\nbe necessary (depending on what the script does and how it is\nwritten) to tell where you are in the working tree (or if you are in\nthe working tree in the first place).\n\n"},{"id":"493826","messageId":"CANHPH1-rdP6V_9P3mA+hMpDqVGkskBqrL6tJLYfePBv=WutCjg@mail.gmail.com","threadId":"61322","inReplyTo":"xmqqedamzo17.fsf@gitster.g","subject":"Re: Re* Unexpected behavior with the rev-parse operation","fromName":"Toru Okugawa","fromEmail":"castor.4bit@gmail.com","sentAt":"2024-05-01T04:55:44Z","receivedAt":"2024-05-01T04:55:56Z","isPatch":false,"sender":{"key":"castor.4bit@gmail.com","avatar":"https://gravatar.com/avatar/8ace42971ee27f54e429f97234431223f0bfa923fcc565ea1f17e8cf50809f47?d=mp&s=160"},"body":"On Wed, May 1, 2024 at 3:46 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> When you write a script that you might want to use as a part of a\n> hook, for example, you may end up running it inside .git/ and it may\n> be necessary (depending on what the script does and how it is\n> written) to tell where you are in the working tree (or if you are in\n> the working tree in the first place).\n\nI misunderstood the purpose of the option initially, but now I\nunderstand it. Thank you for your explanation.\n"}]}