From: Junio C Hamano <gitster@pobox.com>
To: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] replay: replace the_repository with repo parameter passed to cmd_replay()
Date: Wed, 14 May 2025 15:10:44 -0700 [thread overview]
Message-ID: <xmqqplga7sij.fsf@gitster.g> (raw)
In-Reply-To: <pull.1921.git.1747254806067.gitgitgadget@gmail.com> (Elijah Newren via GitGitGadget's message of "Wed, 14 May 2025 20:33:25 +0000")
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> require it and have no current alternatives. However, I still think it's
> worthwhile to stop using the_repository everywhere while ignoring the
> repo parameter explicitly passed in.
Sensible.
> diff --git a/builtin/replay.c b/builtin/replay.c
> index 032c172b65e..225cef08807 100644
> --- a/builtin/replay.c
> +++ b/builtin/replay.c
> @@ -20,21 +20,22 @@
> #include <oidset.h>
> #include <tree.h>
>
> -static const char *short_commit_name(struct commit *commit)
> +static const char *short_commit_name(struct repository *repo,
> + struct commit *commit)
> {
> - return repo_find_unique_abbrev(the_repository, &commit->object.oid,
> + return repo_find_unique_abbrev(repo, &commit->object.oid,
> DEFAULT_ABBREV);
> }
I do not mind this, but I do have to wonder if it is simpler to make
the two callers of this "helper" (which is not quite helping anything)
to make these calls themselves.
> int cmd_replay(int argc,
> const char **argv,
> const char *prefix,
> - struct repository *repo UNUSED)
> + struct repository *repo)
> {
> const char *advance_name_opt = NULL;
> char *advance_name = NULL;
> @@ -329,7 +334,7 @@ int cmd_replay(int argc,
> "--advance", "--contained");
> advance_name = xstrdup_or_null(advance_name_opt);
>
> - repo_init_revisions(the_repository, &revs, prefix);
> + repo_init_revisions(repo, &revs, prefix);
OK, since this command is marked as RUN_SETUP, it is safe to
unconditionally use repo here. The only situation where it is
called with repo==NULL is when somebody said "git replay -h" outside
a repository, which would have made parse_options() to do the right
thing and exited already without reaching this code, so we should be
able to trust "repo" to be usable.
Will queue. Thanks.
next prev parent reply other threads:[~2025-05-14 22:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 20:33 [PATCH] replay: replace the_repository with repo parameter passed to cmd_replay() Elijah Newren via GitGitGadget
2025-05-14 22:10 ` Junio C Hamano [this message]
2025-05-15 13:24 ` Patrick Steinhardt
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=xmqqplga7sij.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@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.