public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lidong Yan <502024330056@smail.nju.edu.cn>
Cc: git@vger.kernel.org,  ayu.chandekar@gmail.com,
	christian.couder@gmail.com,  shyamthakkar001@gmail.com
Subject: Re: [PATCH v2] git.c: remove the_repository dependence in run_builtin()
Date: Sun, 15 Jun 2025 17:53:22 -0700	[thread overview]
Message-ID: <xmqqsek04id9.fsf@gitster.g> (raw)
In-Reply-To: <BE43915C-E780-4166-9C23-81F9A8CBDEDC@smail.nju.edu.cn> (Lidong Yan's message of "Sun, 15 Jun 2025 09:49:55 +0800")

Lidong Yan <502024330056@smail.nju.edu.cn> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>> Sorry, but the above makes it sound as if 246deeac (environment:
>> make `get_git_dir()` accept a repository, 2024-09-12) that retired
>> get_git_dir() and introduced repo_get_git_dir() was the culprit that
>> made their semantics change, but is that really true?  It appears
>> that in the version immediately before that commit, get_git_dir()
>> was also a reference to a variable, without any lazy initialization
>> the above message says that the code tries to avoid, so I am even
>> more confused after reading the above.
>
> I was reading the code in master and noticed that repo_get_git_dir()
> no longer sets up the environment. I’ve learned that I should use git blame
> to identify which commit changed the code, so I can make my message clearer.
>
>> Perhaps you have 73f192c9 (setup: don't perform lazy initialization
>> of repository state, 2017-06-20) in mind?  That one did stop calling
>> setup_git_env() and instead force a hard BUG("") when git_dir is not
>> set up yet.  And that BUG("") still survives in repo_get_git_dir()
>> we have today.
>
> Exactly
>
>> So the call to repo_get_git_dir() may still not be made from this
>> code path.  It may not attempt to set up, but instead it would die
>> if we haven't successfully set up the repository before.  The
>> relevance of the comment was not changed by 246deeac that moved this
>> code from get_git_dir() to repo_get_git_dir(), and more importantly,
>> it was not changed by this patch we are reviewing here.
>> 
>> But stepping back a bit, is it what a9ca8a85 originally wanted to
>> achieve with this comment to "avoid calling get_git_dir()" in the
>> first place?  Once the guarding condition is satisfied, it calls
>> trace_repo_setup(), which in turn calls get_git_dir() anyway.
>> Perhaps it wanted to explain why startup_info->have_repository is
>> checked here?
>
> Yes, I think so. Maybe updating the comment to say 
> “call repo_get_git_dir() after setting up the_repository”
> would be more appropriate.

I do not think so.

e5b17bda (git: ensure correct git directory setup with -h,
2021-12-06) unfortunately moved lines around and made it look like
the comment is about what happens when the if() condition holds, but
if we look at the way how a9ca8a85 (builtins: print setup info if
repo is found, 2010-11-26) initially placed this comment, we can see
that this comment was to only explain the reason why we look at
startup_info->have_repository there.  "Only if we know we have
repository, do the trace_repo_setup() thing because that one calls
get_git_dir() that would die otherwise" is what the comment wants to
say, and if we revert the moving-line-around done by e5b17bda to
recover the original layout in a9ca8a85, I think it is clear enough.

But the theme of this patch is not about improving the comment
anyway, so it should probably be done as a separate patch (if we
really cared, that is).

Thanks.

  reply	other threads:[~2025-06-16  0:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12  4:59 [PATCH] git.c: remove the_repository dependence in run_builtin() Lidong Yan
2025-06-12 17:16 ` Junio C Hamano
2025-06-13  1:53   ` lidongyan
2025-06-13  4:49     ` Junio C Hamano
2025-06-14  5:03 ` [PATCH v2] " Lidong Yan
2025-06-14 23:35   ` Junio C Hamano
2025-06-15  1:49     ` Lidong Yan
2025-06-16  0:53       ` Junio C Hamano [this message]
2025-06-16  5:36         ` Lidong Yan
2025-06-16  5:41           ` Junio C Hamano
2025-06-15 14:46   ` [RFC PATCH v3 0/2] small fixes for git.c and setup.c Lidong Yan
2025-06-15 14:46     ` [PATCH v3 1/2] git.c: remove the_repository dependence in run_builtin() Lidong Yan
2025-06-15 14:46     ` [PATCH v3 2/2] setup: fix NEEDSWORK in setup_git_directory_gently() Lidong Yan
2025-06-16  1:25     ` [RFC PATCH v3 0/2] small fixes for git.c and setup.c Junio C Hamano
2025-06-16  1:36       ` Lidong Yan
2025-06-16  6:22     ` [PATCH v4] git.c: remove the_repository dependence in run_builtin() Lidong Yan

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=xmqqsek04id9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=502024330056@smail.nju.edu.cn \
    --cc=ayu.chandekar@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=shyamthakkar001@gmail.com \
    /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