From: Junio C Hamano <gitster@pobox.com>
To: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v3 5/5] setup: report when GIT_OBJECT_DIRECTORY is what we could not use
Date: Wed, 28 Oct 2026 12:27:38 -0700 [thread overview]
Message-ID: <xmqq4ie5aamt.fsf@gitster.g> (raw)
In-Reply-To: <20261028115412.169748-6-kaartic.sivaraam@gmail.com> (Kaartic Sivaraam's message of "Wed, 28 Oct 2026 17:24:03 +0530")
Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
> Improve this error reporting UX by explaining the real cause wherever
> we are about to die. Because the check does not depend on the candidate
> that is given to is_git_directory(), it is enough to ask once, at the
> point of failure, whether the configured object directory is to blame.
> With this, the user would see the following:
>
> ...
> $ git status
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> cannot access object directory '/tmp/git-objects' set via
> $GIT_OBJECT_DIRECTORY: No such file or directory
Hmph, this is only a half of the real story isn't it?
$ git status ;# to show I am in a healthy repository
on branch master
nothing to commit (use -u to show untracked files)
In such a healthy repository, if I have a bogus DB_ENVIRONMENT,
discovery does not have to fail.
$ GIT_OBJECT_DIRECTORY=/ git status
fatal: bad object HEAD
On the other hand, if I am truly in a bogus non-repository,
it does not matter where DB_ENVIRONMENT points at.
$ (cd / && GIT_OBJECT_DIRECTORY=. git status)
fatal: not a git repository (or any of the parent directories): .git
Even when DB_ENVIRONMENT points at a valid object directory
$ (cd / && GIT_OBJECT_DIRECTORY=$HOME/w/git.git/.git/objects git status)
fatal: not a git repository (or any of the parent directories): .git
the command fails because it cannot find a valid repository.
> +static int describe_unusable_object_dir(struct strbuf *out)
> +{
> + const char *objdir = getenv(DB_ENVIRONMENT);
> + int saved_errno;
> +
> + if (!objdir || !access(objdir, X_OK))
> + return 0;
> + saved_errno = errno;
> +
> + /*
> + * TRANSLATORS: The first %s is a path, the second %s is the
> + * name of the environment variable that set it, and the third
> + * %s is the system error message.
> + */
> + strbuf_addf(out, _("cannot access object directory '%s' set via $%s: %s"),
> + objdir, DB_ENVIRONMENT, strerror(saved_errno));
> + return 1;
> +}
As this is called ONLY when we cannot figure out a usable GIT_DIR,
we do not have to worry about a case where $GIT_OBJECT_DIRECTORY is
not set and $GIT_DIR/objects/ is not readable. So I do not think
this additional message hurts much, but I am not sure how much it
would help. It would make the message more confusing in the "no
valid repository, DB_ENVIRONMENT pointing at a healthy object
directory" situation in the above example.
next prev parent reply other threads:[~2026-10-28 19:27 UTC|newest]
Thread overview: 30+ 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-10-28 11:57 ` Kaartic Sivaraam
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
2026-10-28 11:53 ` [PATCH v3 0/5] Improve error reporting to mention how a Git repository is discovered Kaartic Sivaraam
2026-10-28 11:53 ` [PATCH v3 1/5] setup: normalize an if-else to follow our convention Kaartic Sivaraam
2026-10-28 11:54 ` [PATCH v3 2/5] t0009: add tests to cover more repository discovery scenarios Kaartic Sivaraam
2026-10-28 11:54 ` [PATCH v3 3/5] setup: provide hint about the source of the explicit git directory Kaartic Sivaraam
2026-10-28 11:54 ` [PATCH v3 4/5] setup: provide hint about auto-discovery boundaries Kaartic Sivaraam
2026-10-28 18:57 ` Junio C Hamano
2026-10-28 11:54 ` [PATCH v3 5/5] setup: report when GIT_OBJECT_DIRECTORY is what we could not use Kaartic Sivaraam
2026-10-28 19:27 ` Junio C Hamano [this message]
2026-10-28 19:28 ` [PATCH v3 0/5] Improve error reporting to mention how a Git repository is discovered Junio C Hamano
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=xmqq4ie5aamt.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kaartic.sivaraam@gmail.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.