From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Git mailing list <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC PATCH v2 4/4] setup: communicate why a directory is not a valid git directory
Date: Mon, 5 Oct 2026 17:59:23 +0530 [thread overview]
Message-ID: <b829d416-f36e-454e-a141-3fc93fd62cb3@gmail.com> (raw)
In-Reply-To: <ar0ywAlMDuzK1Hvb@pks.im>
On 9/30/26 21:33, Patrick Steinhardt wrote:
> On Tue, Sep 29, 2026 at 03:55:10PM +0530, Kaartic Sivaraam wrote:
>> At the moment, there are a few scenarios in which the error message
>> surrounding an invalid Git repository is a bit blunt:
>>
>> $ GIT_OBJECT_DIRECTORY=/does/not/exist git --git-dir repo.git rev-parse --is-bare-repository
>> fatal: not a git repository: 'repo.git'
>>
>> In this case, even though repo.git is a valid Git repository,
>> we get an output saying it is not since the GIT_OBJECT_DIRECTORY
>> does not point to a valid object directory. At the moment, the
>> user is on their own in figuring this out.
>>
>> Instead, make it more easy for users to figure such issues
>
> s/more easy/easier/
>
Ah. Will correct.
>> particularly in cases where they have explicitly specified
>> a Git directory. This intends to improve the error reporting UX
>> by clarifying why the specified repository is not considered valid.
>
> Which I think is a good motivation.
>
>> We achieve this by means of using the new helper
>> is_git_directory_verbose() that has been introduced. With the
>> same, we get a more helpful error message as follows:
>>
>> $ GIT_OBJECT_DIRECTORY=/does/not/exist git --git-dir repo.git rev-parse --is-bare-repository
>> fatal: not a git repository: 'repo.git'
>> reason: cannot access object directory '/does/not/exist' set via $GIT_OBJECT_DIRECTORY
>
> Having a separate "reason:" line feels a bit off to me, but that may be
> subjective. I'd have preferred to have it on the same line, or maybe
> first have "error:" followed by "fatal:".
>
Hmm. Let me think which of these I could adopt. Thank you for the
suggestion.
>> diff --git a/setup.c b/setup.c
>> index a0fb68f7f6..a0d3c0c5bb 100644
>> --- a/setup.c
>> +++ b/setup.c
>> @@ -1195,6 +1195,7 @@ static void repo_discover_explicit_gitdir(struct repo_discovery *discovery,
>> int *nongit_ok)
>> {
>> const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
>> + struct strbuf invalid_gitdir_reason = STRBUF_INIT;
>
> Nit, please feel free to ignore: I'd just have called this `errbuf`.
>
Noted.
--
Sivaraam
prev parent reply other threads:[~2026-10-05 12:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 12:02 [RFC PATCH 0/3] Improve error reporting to mention "why" a directory is not a repository Kaartic Sivaraam
2026-09-24 12:02 ` [RFC PATCH 1/3] t0009: add tests to cover more error reporting scenarios Kaartic Sivaraam
2026-09-24 22:08 ` Junio C Hamano
2026-09-25 13:46 ` Kaartic Sivaraam
2026-09-24 12:02 ` [RFC PATCH 2/3] setup: introduce new helper 'is_git_directory_verbose' Kaartic Sivaraam
2026-09-24 22:11 ` Junio C Hamano
2026-09-25 17:51 ` Kaartic Sivaraam
2026-09-24 12:02 ` [RFC PATCH 3/3] setup: communicate why a directory is not a valid git directory Kaartic Sivaraam
2026-09-24 22:16 ` Junio C Hamano
2026-09-25 14:33 ` Kaartic Sivaraam
2026-09-29 10:25 ` [RFC PATCH v2 0/4] Improve error reporting to mention "why" a directory is not a repository Kaartic Sivaraam
2026-09-29 10:25 ` [RFC PATCH v2 1/4] setup: normalize an if-else to follow our convention Kaartic Sivaraam
2026-09-29 10:25 ` [RFC PATCH v2 2/4] t0009: add tests to cover more error reporting scenarios Kaartic Sivaraam
2026-09-29 10:25 ` [RFC PATCH v2 3/4] setup: introduce new helper 'is_git_directory_verbose' Kaartic Sivaraam
2026-09-30 16:03 ` Patrick Steinhardt
2026-10-05 12:14 ` Kaartic Sivaraam
2026-09-30 18:32 ` Junio C Hamano
2026-09-29 10:25 ` [RFC PATCH v2 4/4] setup: communicate why a directory is not a valid git directory Kaartic Sivaraam
2026-09-30 16:03 ` Patrick Steinhardt
2026-10-05 12:29 ` Kaartic Sivaraam [this message]
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=b829d416-f36e-454e-a141-3fc93fd62cb3@gmail.com \
--to=kaartic.sivaraam@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.