From: Junio C Hamano <gitster@pobox.com>
To: Andrei Rybak <rybak.a.v@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org,
"Christian Couder" <christian.couder@gmail.com>,
"Felipe Contreras" <felipe.contreras@gmail.com>
Subject: Re: [PATCH resend] help: convert git_cmd to page in one place
Date: Thu, 08 Jul 2021 08:12:05 -0700 [thread overview]
Message-ID: <xmqqsg0oc01m.fsf@gitster.g> (raw)
In-Reply-To: <93578e5a-c09b-14c2-8f87-eb354f4b576c@gmail.com> (Andrei Rybak's message of "Thu, 8 Jul 2021 10:07:31 +0200")
Andrei Rybak <rybak.a.v@gmail.com> writes:
> Is reusing "argv[0]" one more time instead of introducing the variable
> "page" is a good idea? It could either be:
>
> argv[0] = cmd_to_page(check_git_cmd(argv[0]));
>
> or
>
> argv[0] = check_git_cmd(argv[0]);
> argv[0] = cmd_to_page(argv[0]);
>
> That way, the quoted hunk above (touching calls to show_*_page) wouldn't
> be in the patch.
It is a bad idea. It gives readers a false impression that there
are users of information other than show_$fmt_page() functions that
do not want the original argv[0] but the variant massaged by the
cmd_to_page() function later in the code after these functions
return, and more importantly, it would make it impossible to recover
the original value of argv[0] if the code later wants to.
To be perfectly honest, I do not see much value in the patch being
discussed (I am not saying "I see no value"---just "not much")
[*1*]. The patch under discussion may not be making things worse,
but overwriting argv[0] WILL make it worse than the current code, I
would think.
[Footnote]
*1* This is because I see nothing wrong in the original code before
applying this patch. How the manual pages are named after the
actual command name may happen to be the same across all three
show_$fmt_page() backends (and that is why they happen to all
call cmd_to_page() helper function), but there is no strong
reason why that has to stay that way. E.g. "man git-cat-file"
is used by the man backend only because cmd_to_page() yields one
'git-cat-file' string, but "man 1 git-cat-file" would equally be
a good way to drive the "man" viewer. Other format backends may
not have good use for the section information---it is more
natural to allow each of show_$fmt_page() to use their own way
to derive where the documentation is found for each command.
prev parent reply other threads:[~2021-07-08 15:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-26 16:32 [PATCH] help: convert git_cmd to page in one place Andrei Rybak
2021-06-26 17:57 ` Felipe Contreras
2021-07-04 15:39 ` [PATCH resend] " Andrei Rybak
2021-07-05 6:15 ` Ævar Arnfjörð Bjarmason
2021-07-06 20:11 ` Junio C Hamano
2021-07-08 8:07 ` Andrei Rybak
2021-07-08 15:12 ` Junio C Hamano [this message]
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=xmqqsg0oc01m.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=rybak.a.v@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;
as well as URLs for NNTP newsgroup(s).