public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>, git@vger.kernel.org
Cc: gitster@pobox.com, karthik.188@gmail.com
Subject: Re: [PATCH 1/3] wt-status: replace uses of the_repository with local repository instances
Date: Tue, 3 Feb 2026 10:58:05 +0000	[thread overview]
Message-ID: <50791aed-c64b-48fe-8cc7-8cacaec9d295@gmail.com> (raw)
In-Reply-To: <20260202190155.79896-1-shreyanshpaliwalcmsmn@gmail.com>

On 02/02/2026 18:57, Shreyansh Paliwal wrote:
>>> Many instances of the_repository are used in wt-status.c even when a
>>> local repository is already available via struct wt_status or struct
>>> worktree.
>>>
>>
>> One missing information is why is it safe to make this change? If is a
>> repository field, is it holding the same information, is it always
>> defined?
> 
> Yes I should have included explanation as well.
> I have explained below, let me know if this thought process
> is valid or not.
> 
> The replacement of all the_repository with s->repo in this patch are mostly
> to cases where a repository instance is already available via struct wt_status.
> 
> In the current flow, all functions operating on struct wt_status *s
> are called via commit.c. There, status_init_config() calls
> wt_status_prepare(), which initializes the struct wt_status and
> assigns s->repo from the repository instance passed in by the caller.
> As a result, s->repo is guaranteed to be initialized whenever these
> functions are invoked.
> 
> And commit.c itself still relies on the_repository, within wt-status.c,
> the local repository pointer refers to the same underlying
> repository object that the_repository would have pointed to, indirectly
> until we make commit.c also free of the_repository.

Good explanation, that would be a very useful addition to the commit message

>>> diff --git a/wt-status.c b/wt-status.c
>>> index e12adb26b9..9f4d8fda7f 100644
>>> --- a/wt-status.c
>>> +++ b/wt-status.c
>>> @@ -150,11 +150,11 @@ void wt_status_prepare(struct repository *r, struct wt_status *s)
>>> 	s->show_untracked_files = SHOW_NORMAL_UNTRACKED_FILES;
>>> 	s->use_color = GIT_COLOR_UNKNOWN;
>>> 	s->relative_paths = 1;
>>> -	s->branch = refs_resolve_refdup(get_main_ref_store(the_repository),
>>> +	s->branch = refs_resolve_refdup(get_main_ref_store(s->repo),
>>> 					"HEAD", 0, NULL, NULL);
>>
>> Wouldn't it make more sense to use the function argument 'r' here?
> 
> In wt_status_prepare(), s->repo is initialized to r at the top of
> the function, so both refer to the same repository instance. However,
> using r directly is more explicit and avoids indirect use.
> will change this in V2.

Yes, a few more context lines makes it is clear that either is safe.

>>> @@ -1723,18 +1723,18 @@ int wt_status_check_rebase(const struct worktree *wt,
>>>   {
>>> 	struct stat st;
>>>
>>> -	if (!stat(worktree_git_path(the_repository, wt, "rebase-apply"), &st)) {
>>> -		if (!stat(worktree_git_path(the_repository, wt, "rebase-apply/applying"), &st)) {
>>> +	if (!stat(worktree_git_path(wt->repo, wt, "rebase-apply"), &st)) {
>>> +		if (!stat(worktree_git_path(wt->repo, wt, "rebase-apply/applying"), &st)) {
>>
>> In the same file we make a call 'wt_status_check_rebase(NULL, state)',
>> so wouldn't this break?
> 
> Yes my bad, it would throw a segfault error.
> I think the best way to handle this is to explicitly check for the
> wt to be valid like this,
> 
>      if (wt==NULL)
>          return 0;

That would change the behavior of the function though as it will no 
longer check if the rebase directories exist. You should pass the 
repository down from the caller.

Thanks for working on this

Phillip

> Falling back to the_repository in this case, would probably
> defeat the purpose.
> 


  parent reply	other threads:[~2026-02-03 10:58 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-31 18:57 [PATCH 0/3] wt-status: reduce reliance on global state Shreyansh Paliwal
2026-01-31 18:57 ` [PATCH 1/3] wt-status: replace uses of the_repository with local repository instances Shreyansh Paliwal
2026-02-02 10:02   ` Karthik Nayak
2026-02-02 18:42     ` Junio C Hamano
2026-02-02 18:57     ` Shreyansh Paliwal
2026-02-02 22:41       ` Junio C Hamano
2026-02-02 23:03         ` Junio C Hamano
2026-02-03  9:53           ` Shreyansh Paliwal
2026-02-03 11:06             ` Phillip Wood
2026-02-03 15:20               ` Shreyansh Paliwal
2026-02-03 10:58       ` Phillip Wood [this message]
2026-02-03 15:15         ` Shreyansh Paliwal
2026-01-31 18:57 ` [PATCH 2/3] wt-status: pass struct repository and wt_status through function parameters Shreyansh Paliwal
2026-01-31 18:57 ` [PATCH 3/3] wt-status: use hash_algo from local repository instead of global the_hash_algo Shreyansh Paliwal
2026-02-02 10:03   ` Karthik Nayak
2026-02-02 19:03     ` Shreyansh Paliwal
2026-02-04 10:18       ` Karthik Nayak
2026-02-04 11:22         ` Shreyansh Paliwal
2026-02-05 10:13 ` [PATCH V2 0/3] wt-status: reduce reliance on global state Shreyansh Paliwal
2026-02-05 10:13   ` [PATCH V2 1/3] wt-status: replace uses of the_repository with local repository instances Shreyansh Paliwal
2026-02-05 10:59     ` Karthik Nayak
2026-02-05 11:11       ` Karthik Nayak
2026-02-05 12:18         ` Shreyansh Paliwal
2026-02-05 16:08           ` Phillip Wood
2026-02-05 17:41             ` Shreyansh Paliwal
2026-02-05 10:13   ` [PATCH V2 2/3] wt-status: pass struct repository and wt_status through function parameters Shreyansh Paliwal
2026-02-05 11:09     ` Karthik Nayak
2026-02-05 12:04       ` Shreyansh Paliwal
2026-02-06  9:24         ` Karthik Nayak
2026-02-06  9:32           ` Shreyansh Paliwal
2026-02-06 12:57             ` Shreyansh Paliwal
2026-02-06 14:54               ` Phillip Wood
2026-02-06 17:06                 ` Shreyansh Paliwal
2026-02-05 15:58       ` Phillip Wood
2026-02-05 10:13   ` [PATCH V2 3/3] wt-status: use hash_algo from local repository instead of global the_hash_algo Shreyansh Paliwal
2026-02-05 10:27   ` [PATCH V2 0/3] wt-status: reduce reliance on global state Shreyansh Paliwal
2026-02-05 15:53     ` Phillip Wood
2026-02-05 17:39       ` Shreyansh Paliwal
2026-02-05 18:02         ` Kristoffer Haugsbakk
2026-02-05 18:18           ` Shreyansh Paliwal
2026-02-07 10:00   ` [PATCH v3 " Shreyansh Paliwal
2026-02-07 10:00     ` [PATCH v3 1/3] wt-status: pass struct repository through function parameters Shreyansh Paliwal
2026-02-08  1:14       ` Junio C Hamano
2026-02-08  4:55         ` [PATCH V2 2/3] wt-status: pass struct repository and wt_status " Shreyansh Paliwal
2026-02-09  8:36         ` [PATCH v3 1/3] wt-status: pass struct repository " Karthik Nayak
2026-02-08  1:21       ` Junio C Hamano
2026-02-08  4:44         ` [PATCH V2 2/3] wt-status: pass struct repository and wt_status " Shreyansh Paliwal
2026-02-08  6:08           ` Junio C Hamano
2026-02-08 15:25             ` Shreyansh Paliwal
2026-02-09  9:02               ` Karthik Nayak
2026-02-09 13:43                 ` Shreyansh Paliwal
2026-02-09 16:13                 ` Junio C Hamano
2026-02-10  9:50                   ` Karthik Nayak
2026-02-07 10:00     ` [PATCH v3 2/3] wt-status: replace uses of the_repository with local repository instances Shreyansh Paliwal
2026-02-07 10:00     ` [PATCH v3 3/3] wt-status: use hash_algo from local repository instead of global the_hash_algo Shreyansh Paliwal
2026-02-17 17:29 ` [PATCH v4 0/3] wt-status: reduce reliance on global state Shreyansh Paliwal
2026-02-17 17:29   ` [PATCH v4 1/3] wt-status: pass struct repository through function parameters Shreyansh Paliwal
2026-02-17 17:29   ` [PATCH v4 2/3] wt-status: replace uses of the_repository with local repository instances Shreyansh Paliwal
2026-02-17 17:29   ` [PATCH v4 3/3] wt-status: use hash_algo from local repository instead of global the_hash_algo Shreyansh Paliwal
2026-02-18 16:13   ` [PATCH v4 0/3] wt-status: reduce reliance on global state Phillip Wood
2026-02-18 16:48     ` Shreyansh Paliwal
2026-02-18 17:53 ` [PATCH v5 " Shreyansh Paliwal
2026-02-18 17:53   ` [PATCH v5 1/3] wt-status: pass struct repository through function parameters Shreyansh Paliwal
2026-02-18 17:53   ` [PATCH v5 2/3] wt-status: replace uses of the_repository with local repository instances Shreyansh Paliwal
2026-02-18 17:53   ` [PATCH v5 3/3] wt-status: use hash_algo from local repository instead of global the_hash_algo Shreyansh Paliwal
2026-03-06 22:31   ` [PATCH v5 0/3] wt-status: reduce reliance on global state Junio C Hamano
2026-03-09 10:32     ` Karthik Nayak
2026-03-09 18:30       ` Junio C Hamano
2026-03-09 10:35     ` Phillip Wood

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=50791aed-c64b-48fe-8cc7-8cacaec9d295@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=shreyanshpaliwalcmsmn@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