All of lore.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 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.