From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Philip Peterson via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Philip Peterson <philip.c.peterson@gmail.com>
Subject: Re: [PATCH 2/2] apply: do not use the_repository
Date: Tue, 28 May 2024 09:33:07 -0700 [thread overview]
Message-ID: <xmqqh6eh7v7g.fsf@gitster.g> (raw)
In-Reply-To: <ZlWHgBROsPBrmM0D@tanuki> (Patrick Steinhardt's message of "Tue, 28 May 2024 09:28:00 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, May 28, 2024 at 06:32:01AM +0000, Philip Peterson via GitGitGadget wrote:
>> diff --git a/apply.c b/apply.c
>> index 901b67e6255..364c05fbd06 100644
>> --- a/apply.c
>> +++ b/apply.c
>> @@ -3218,13 +3218,13 @@ static int apply_binary(struct apply_state *state,
>> return 0; /* deletion patch */
>> }
>>
>> - if (has_object(the_repository, &oid, 0)) {
>> + if (has_object(state->repo, &oid, 0)) {
>> /* We already have the postimage */
>> enum object_type type;
>> unsigned long size;
>> char *result;
>>
>> - result = repo_read_object_file(the_repository, &oid, &type,
>> + result = repo_read_object_file(state->repo, &oid, &type,
>> &size);
>> if (!result)
>> return error(_("the necessary postimage %s for "
>
> We call `get_oid_hex()` in this function, which ultimately ends up
> accessing `the_repository` via `the_hash_algo`. We should likely convert
> those to `repo_get_oid()`.
>
> There are also other accesses to `the_hash_algo` in this function, which
> should be converted to use `state->repo->hash_algo`, as well.
We as a more experienced developers should come up with a way to
help developers who are less familiar with the API set, so that they
can chip in this effort to wean ourselves off of globals.
Would a bug like the ones you pointed out be easily caught by say
running "GIT_TEST_DEFAULT_HASH=sha256 make test"?
By the way, for commands like "git apply" that can and does work
outside a repository, a change to use state->repo instead of
the_repository is only half a story. Dealing with cases where there
is no repository is the other half. I _think_ we have drawn a
reasonable line to punt and refuse binary patches and three-way
fallback outside a repository, but there may be use cases that
benefit from being able to do these things in a tarball extract.
next prev parent reply other threads:[~2024-05-28 16:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 6:31 [PATCH 0/2] Remove some usages of the_repository Philip Peterson via GitGitGadget
2024-05-28 6:32 ` [PATCH 1/2] add-patch: do not use the_repository Philip Peterson via GitGitGadget
2024-05-28 21:41 ` Junio C Hamano
2024-05-28 6:32 ` [PATCH 2/2] apply: " Philip Peterson via GitGitGadget
2024-05-28 7:28 ` Patrick Steinhardt
2024-05-28 16:33 ` Junio C Hamano [this message]
2024-05-28 17:22 ` Patrick Steinhardt
2024-05-28 17:37 ` Junio C Hamano
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=xmqqh6eh7v7g.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=philip.c.peterson@gmail.com \
--cc=ps@pks.im \
/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;
as well as URLs for NNTP newsgroup(s).