git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Navero <knavero@gmail.com>
To: git@vger.kernel.org
Subject: Opening git-bash from git-gui and cd'ing to the root of the filesystem results in git-bash thinking it is at the top-level of the repo
Date: Mon, 28 Oct 2024 13:19:57 -0700	[thread overview]
Message-ID: <CACRG6_ApLKqnVrvQziUtF4nkquk_HPiXTMR-NDdx85BSN1ng4g@mail.gmail.com> (raw)

Hi,

Generated this bug report using git-bugreport:

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

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

    Note: Was redirected from
[here](https://github.com/git-for-windows/git/issues/5234), on the
speculation that the bug report might not be Windows-specific.

    1. Open git-gui from the Windows start menu (or whatever the
equivalent on Linux is)
    2. Select an existing repo, either through `Open Existing
Repository` or one of the paths below `Open Recent Repository`
    3. From the top menu, click `Repository`, click `Git Bash`
    4. In git-bash, `cd /` (expecting `/` to *not* to be a git repo),
then `git status`

What did you expect to happen? (Expected behavior)

    fatal: not a git repository (or any of the parent directories): .git

What happened instead? (Actual behavior)

    On branch foo
    Your branch is up to date with 'origin/foo'.

    nothing to commit, working tree clean

What's different between what you expected and what actually happened?

    The output messages. The expected behavior is to fatal. The actual
behavior did *not* fatal. In both cases, the current working directory
is at the filesystem root, which is expected to not be a git repo.

Anything else you want to add:

    It seems that what is affecting this is that opening up git-gui
sets the `GIT_DIR` env var automatically. The resulting behavior seems
somewhat non-intuitive and confused myself and a colleague. The
resulting behavior I expected was the behavior one would get if
git-gui spawned a git-bash shell with the current working directory
set to the repo's path, but *without* setting `GIT_DIR`.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.

    [System Info]
    git version:
    git version 2.45.0.windows.1
    cpu: x86_64
    built from commit: b5d0511969ccd9ab86395c37e5a7619d8b4e7c32
    sizeof-long: 4
    sizeof-size_t: 8
    shell-path: /bin/sh
    feature: fsmonitor--daemon
    uname: Windows 10.0 19045
    compiler info: gnuc: 13.2
    libc info: no libc information available
    $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


    [Enabled Hooks]
    post-checkout
    post-commit
    post-merge
    pre-push

- Kevin Navero

                 reply	other threads:[~2024-10-28 20:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACRG6_ApLKqnVrvQziUtF4nkquk_HPiXTMR-NDdx85BSN1ng4g@mail.gmail.com \
    --to=knavero@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).