Describe the bug

The gh repo create --source DIR command may fail with a misleading and incorrect error message.

This happens if, for example, DIR is a local work tree that uses a non-standard location for its .git directory.

Version info:

$ gh --version
gh version 2.40.1 (2023-12-13)
https://github.com/cli/cli/releases/tag/v2.40.1

Steps to reproduce the behavior

1. Create a local repository in a non-standard location, e.g. .git2:

   cd "$(mktemp -d)"
   export GIT_DIR="$(pwd)/.git2"
   export GIT_WORK_TREE="$(pwd)"
   git init
   git commit --allow-empty -m 'Initial commit'

2. Create a GitHub repository:

   # Note: substitute `myowner/myrepo` with an appropriate value
   gh repo create --private myowner/myrepo -s .

Expected vs actual behavior

I expect the gh repo create invocation to succeed.

Instead, it prints the following error message:

current directory is not a git repository. Run git init to initialize it

Why the behavior is incorrect

I think that this error message is misleading, because:

• Contrary to what the error message says, the current directory actually is a perfectly good Git repository.

• Throughout the project, the code appears to be generally aware that repository paths are configurable.
  In one instance though, it has the .git string hard coded, causing the above error message. (See Analysis for details.)

Why this is important

Git repositories that live at some other path than .git can be part of several useful workflows, even if they’re not bare Git repositories.

(For example, a developer may want to keep textual notes as Markdown files next to their code, and be able to track these notes even while checking out an earlier commit, during an interactive rebase, or during a git bisect session. To that end, they might want to keep those notes in a secondary Git repository named e.g. .git2 or .notes.)

Analysis

According to the comment next to the isLocalRepo function, the purpose of the function is to:

check if path is the top level directory of a git repo

In an attempt to figure out whether we’re on the top level directory, the code insideisLocalRepo first calls the equivalent of git rev-parse --git-dir. It then assumes that if and only if the current directory is on the top level, then the output is a) a relative path, which b) points to the .git directory.

Both assumptions a) and b) are wrong. This leads to false alarms in several cases, including this bug.

Suggested fix

To fix the issue, I suggest that rather than call GitDir, the isLocalRepo function use the ToplevelDir and PathFromRoot functions instead.

The proposed functions already exist in the code base; they’re used by the browse and pr modules. Internally, they run git rev-parse --show-toplevel and git rev-parse --show-prefix, respectively, which represents the standard, Git-supported way to figure out where we are.

Would you consider reviewing a PR for this?