From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: "David Aguilar" <davvid@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Elijah Newren" <newren@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] difftool: eliminate use of global variables
Date: Wed, 05 Feb 2025 09:30:41 -0800 [thread overview]
Message-ID: <xmqq7c64pada.fsf@gitster.g> (raw)
In-Reply-To: <Z6MThg8oEEtx5xur@pks.im> (Patrick Steinhardt's message of "Wed, 5 Feb 2025 08:30:14 +0100")
Patrick Steinhardt <ps@pks.im> writes:
>> +struct difftool_state {
>> + int has_symlinks;
>> + int symlinks;
>> + int trust_exit_code;
>> +};
>
> Why do we have both `has_symlinks` and `symlinks`? The latter gets set
> to `has_symlinks` anyway, so it's a confusing to have both.
I had the same reaction, but one aspect of the topic is about
"encapsulate the existing globals into a state structure", and since
these two are there in the original as globals, it would be easier
to validate the correctness of the conversion to have both in the
struct to keep the rewrite more faithful to the original. It would
be more appropriate to do it in a separate step to turn them into
one, if (I haven't thought about it, so this is still an "if" to me)
it makes the results easier to follow.
The other aspect to lose the reference to the_repository indeed can
be presented as a separate and independent change, and that may make
the patch easier to view.
> Also, I think it would make sense to rename the struct to
> `difftool_options`, as it tracks options rather than state.
Great suggestion.
Thanks.
next prev parent reply other threads:[~2025-02-05 17:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 22:55 [PATCH] difftool: eliminate use of global variables David Aguilar
2025-02-05 7:30 ` Patrick Steinhardt
2025-02-05 17:30 ` Junio C Hamano [this message]
2025-02-05 14:08 ` 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=xmqq7c64pada.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@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).