public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
To: 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 00:27:14 +0530	[thread overview]
Message-ID: <20260202190155.79896-1-shreyanshpaliwalcmsmn@gmail.com> (raw)
In-Reply-To: <CAOLa=ZRv4xsy0adY_BcXQkypsgYkLNM6x5LhJGX+B+=aKCwmgg@mail.gmail.com>

> > 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.

> > 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.

> > @@ -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;

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

  parent reply	other threads:[~2026-02-02 19:02 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 [this message]
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
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=20260202190155.79896-1-shreyanshpaliwalcmsmn@gmail.com \
    --to=shreyanshpaliwalcmsmn@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@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