Unexpected behavior with the rev-parse operation

Unexpected behavior with the rev-parse operation

[Toru Okugawa]

Hi,

I have encountered some unexpected behavior with the rev-parse operation.

---
What did you do before the bug happened? (Steps to reproduce your issue)

```
$ mkdir -p /tmp/example
$ cd $_
$ ls -a
.  ..

$ git rev-parse --is-inside-work-tree
fatal: not a git repository (or any of the parent directories): .git
```

What did you expect to happen? (Expected behavior)

If the current working directory is outside the work tree, the
documentation says that `git rev-parse --is-inside-work-tree` will
output false.
https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt---is-inside-work-tree

```
$ git rev-parse --is-inside-work-tree
false
```

What happened instead? (Actual behavior)

It will output `fatal: not a git repository (or any of the parent
directories): .git` and exit with code 128. The `--is-inside-git-dir`
option works the same way.

```
$ git rev-parse --is-inside-work-tree
fatal: not a git repository (or any of the parent directories): .git
```

[System Info]
git version:
git version 2.44.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:53
PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 arm64
compiler info: clang: 15.0.0 (clang-1500.1.0.2.5)
libc info: no libc information available
$SHELL (typically, interactive shell): /opt/homebrew/bin/zsh


Thanks

Re: Unexpected behavior with the rev-parse operation

[Eric Sunshine]

On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:
> I have encountered some unexpected behavior with the rev-parse operation.
> ---
> $ ls -a
> .  ..
> $ git rev-parse --is-inside-work-tree
> fatal: not a git repository (or any of the parent directories): .git
>
> What did you expect to happen? (Expected behavior)
>
> If the current working directory is outside the work tree, the
> documentation says that `git rev-parse --is-inside-work-tree` will
> output false.
> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt---is-inside-work-tree

I think this is working as intended, but the documentation is lacking
or misleading. With very few exceptions[1], `git rev-parse` expects to
be run either within a Git working tree or within a Git repository
(i.e. the .git/ directory or a bare repository). Options such as
--is-inside-work-tree, --is-bare-repository, etc. are meant to report
upon aspects of the worktree or repository in which the command is
invoked.

Looking at the source code for `git rev-parse`, it does appear that it
has explicit support for the case of checking whether or not the
current directory is a Git worktree or repository. The way to do that
is to run `git rev-parse` without any arguments. However, even in that
case, it will print the "fatal: not a git repository" error. This
means it is your responsibility, as a script writer, to suppress or
capture the error message (whichever is appropriate for your case).
For instance:

    if test git rev-parse >/dev/null 2>&1
    then
        echo "in a Git directory or repository"
    else
        echo "not in a Git directory or repository"
    fi

[1]: --sh-quote, --parse-opt, --local-env-vars, --resolve-git-dir

Re* Unexpected behavior with the rev-parse operation

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:
>> I have encountered some unexpected behavior with the rev-parse operation.
>> ---
>> $ ls -a
>> .  ..
>> $ git rev-parse --is-inside-work-tree
>> fatal: not a git repository (or any of the parent directories): .git
>> ...
> ... This
> means it is your responsibility, as a script writer, to suppress or
> capture the error message (whichever is appropriate for your case).
> For instance:
>
>     if test git rev-parse >/dev/null 2>&1
>     then
>         echo "in a Git directory or repository"
>     else
>         echo "not in a Git directory or repository"
>     fi

All true.  It may however need some documentation updates, though,
something along this line, perhaps?

 Documentation/git-rev-parse.txt | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git c/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt
index f9d5a35fa0..a62d798744 100644
--- c/Documentation/git-rev-parse.txt
+++ w/Documentation/git-rev-parse.txt
@@ -18,8 +18,16 @@ Many Git porcelainish commands take a mixture of flags
 (i.e. parameters that begin with a dash '-') and parameters
 meant for the underlying 'git rev-list' command they use internally
 and flags and parameters for the other commands they use
-downstream of 'git rev-list'.  This command is used to
-distinguish between them.
+downstream of 'git rev-list'.  One purpose of this command is to
+allow calling programs to distinguish between them.
+
+There are a few other operation modes that have noting to do with
+the above "help parse command line options" added to the command.
+
+Unless otherwise specified, most of the options and operation modes
+require you to run this command inside a git repository or a working
+tree that is under control of a git repository, and will give you a
+fatal error otherwise.
 
 
 OPTIONS
@@ -32,11 +40,15 @@ Each of these options must appear first on the command line.
 
 --parseopt::
 	Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
+	The command in this mode can be used outside a repository or
+	a working tree controlled by a repository.
 
 --sq-quote::
 	Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
 	section below). In contrast to the `--sq` option below, this
 	mode only does quoting. Nothing else is done to command input.
+	The command in this mode can be used outside a repository or
+	a working tree controlled by a repository.
 
 Options for --parseopt
 ~~~~~~~~~~~~~~~~~~~~~~

Re: Re* Unexpected behavior with the rev-parse operation

[Toru Okugawa]

On Mon, Apr 29, 2024 at 8:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
> > On Mon, Apr 15, 2024 at 9:58 AM Toru Okugawa <castor.4bit@gmail.com> wrote:
> >> I have encountered some unexpected behavior with the rev-parse operation.
> >> ---
> >> $ ls -a
> >> .  ..
> >> $ git rev-parse --is-inside-work-tree
> >> fatal: not a git repository (or any of the parent directories): .git
> >> ...
> > ... This
> > means it is your responsibility, as a script writer, to suppress or
> > capture the error message (whichever is appropriate for your case).
> > For instance:
> >
> >     if test git rev-parse >/dev/null 2>&1
> >     then
> >         echo "in a Git directory or repository"
> >     else
> >         echo "not in a Git directory or repository"
> >     fi
>
> All true.  It may however need some documentation updates, though,
> something along this line, perhaps?
>
>  Documentation/git-rev-parse.txt | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git c/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt
> index f9d5a35fa0..a62d798744 100644
> --- c/Documentation/git-rev-parse.txt
> +++ w/Documentation/git-rev-parse.txt
> @@ -18,8 +18,16 @@ Many Git porcelainish commands take a mixture of flags
>  (i.e. parameters that begin with a dash '-') and parameters
>  meant for the underlying 'git rev-list' command they use internally
>  and flags and parameters for the other commands they use
> -downstream of 'git rev-list'.  This command is used to
> -distinguish between them.
> +downstream of 'git rev-list'.  One purpose of this command is to
> +allow calling programs to distinguish between them.
> +
> +There are a few other operation modes that have noting to do with
> +the above "help parse command line options" added to the command.
> +
> +Unless otherwise specified, most of the options and operation modes
> +require you to run this command inside a git repository or a working
> +tree that is under control of a git repository, and will give you a
> +fatal error otherwise.
>
>
>  OPTIONS
> @@ -32,11 +40,15 @@ Each of these options must appear first on the command line.
>
>  --parseopt::
>         Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
> +       The command in this mode can be used outside a repository or
> +       a working tree controlled by a repository.
>
>  --sq-quote::
>         Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
>         section below). In contrast to the `--sq` option below, this
>         mode only does quoting. Nothing else is done to command input.
> +       The command in this mode can be used outside a repository or
> +       a working tree controlled by a repository.
>
>  Options for --parseopt
>  ~~~~~~~~~~~~~~~~~~~~~~

Thank you for your responses.

I'm aware that `--is-inside-work-tree` is an option for `git
rev-parse`, and I understand that it is normal for the command to
generate an error when executed outside a Git repository. Indeed, I
have previously used the result of `git rev-parse >/dev/null 2>&1` to
determine whether the directory is inside a Git repository or not.

However, if determining the presence of a Git repository by checking
for errors is the appropriate approach, I'm interested in
understanding the intended use of the `--is-inside-work-tree` option.
I had thought it was meant to suppress errors in exceptional cases.

Re: Re* Unexpected behavior with the rev-parse operation

[Junio C Hamano]

Toru Okugawa <castor.4bit@gmail.com> writes:

> However, if determining the presence of a Git repository by checking
> for errors is the appropriate approach, I'm interested in
> understanding the intended use of the `--is-inside-work-tree` option.
> I had thought it was meant to suppress errors in exceptional cases.

    $ rm -fr mine
    $ git init mine ;# notice the lack of --bare
    $ cd mine
    $ git commit --allow-empty -m 'initial'
    $ git rev-parse --is-inside-work-tree; echo $?
    true
    0
    $ cd .git
    $ git rev-parse --is-inside-work-tree; echo $?
    false
    0
    $ cd ../..
    $ git --bare init mine.bare ;# this time bare
    $ cd mine.bare
    false
    0

When you write a script that you might want to use as a part of a
hook, for example, you may end up running it inside .git/ and it may
be necessary (depending on what the script does and how it is
written) to tell where you are in the working tree (or if you are in
the working tree in the first place).

Re: Re* Unexpected behavior with the rev-parse operation

[Toru Okugawa]

On Wed, May 1, 2024 at 3:46 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> When you write a script that you might want to use as a part of a
> hook, for example, you may end up running it inside .git/ and it may
> be necessary (depending on what the script does and how it is
> written) to tell where you are in the working tree (or if you are in
> the working tree in the first place).

I misunderstood the purpose of the option initially, but now I
understand it. Thank you for your explanation.