All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 5/5] doc lint: lint and fix missing "GIT" end sections
Date: Fri, 26 Mar 2021 16:32:58 +0100	[thread overview]
Message-ID: <87pmzmnd5h.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <YF2/xPMvwhm+OOVz@coredump.intra.peff.net>


On Fri, Mar 26 2021, Jeff King wrote:

> On Fri, Mar 26, 2021 at 11:36:50AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> Lint for and fix the three manual pages that were missing the standard
>> "Part of the linkgit:git[1] suite" end section.
>
> This is a definite improvement. Two thoughts come to mind, though:
>
>   1. Do we need a separate script for this? Couldn't the existing linter
>      script check this while it is reading all of the files (it knows
>      which ones are supposed to be manpages because they are annotated
>      with the --section option).

It's not needed, but I think it's better, one is iterating a
line-at-time, one slurps all lines, they have different sorts of error
reporting (one quotes the whole line).

So I thought about joining them into one, and also make them and
check-non-portable-shell.pl some general lint-line-ish checker.

Obviously all of that fits in one script, but I think for something like
this that's a one-off script with global variables it's much harder to
follow when a large part of your script is some if/else or
keeping/resetting of state simply to work around the script doing two
things instead of one.

I mean, the whole scaffolding is basically:

    use strict;
    use warnings;
    sub report { ... }
    my $code = 0;
    while (<>) {
        ...
    }
    exit $code;

We'd spend more lines effort trying to consolidate them than just
copying that around.

> That would be more efficient, and probably a little less code.

This thing takes ~5ms to run on my (and most) boxes, by comparison the
whole asciidoc dance takes some eons...

>   2. Instead of linting, could we just be automatically sticking this
>      boilerplate in as part of the build (either through some asciidoc
>      magic, or even just a plain old "cat")? Even better than being
>      reminded that you forgot something is making it impossible to
>      forget it in the first place.

Whenever I take an aborted effort at the docs I end up with some aborted
effort to migrte them to texinfo, so I'm sympathetic to the automatic
generation part of this.

But for something trivial like this I think there's more value in having
a 1=1 match between WYS and WYG, not adding magic blurbs by the build
system for something so trivial.

That being said I wouldn't mind it much, just seemed like an obvious
thing to add a lint for as it stands now...


  reply	other threads:[~2021-03-26 15:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 10:36 [PATCH 0/5] small doc make and lint fixes Ævar Arnfjörð Bjarmason
2021-03-26 10:36 ` [PATCH 1/5] Documentation/Makefile: make $(wildcard howto/*.txt) a var Ævar Arnfjörð Bjarmason
2021-03-28  6:14   ` Junio C Hamano
2021-03-26 10:36 ` [PATCH 2/5] Documentation/Makefile: make $(wildcard <doc deps>) " Ævar Arnfjörð Bjarmason
2021-03-28  6:28   ` Junio C Hamano
2021-03-26 10:36 ` [PATCH 3/5] doc lint: Perl "strict" and "warnings" in lint-gitlink.perl Ævar Arnfjörð Bjarmason
2021-03-28  6:28   ` Junio C Hamano
2021-03-26 10:36 ` [PATCH 4/5] doc lint: fix bugs in, simplify and improve lint script Ævar Arnfjörð Bjarmason
2021-03-26 11:00   ` Jeff King
2021-03-28  1:35     ` Junio C Hamano
2021-03-26 12:48   ` Philip Oakley
2021-03-28  1:34     ` Junio C Hamano
2021-03-28  6:38   ` Junio C Hamano
2021-03-26 10:36 ` [PATCH 5/5] doc lint: lint and fix missing "GIT" end sections Ævar Arnfjörð Bjarmason
2021-03-26 11:04   ` Jeff King
2021-03-26 15:32     ` Ævar Arnfjörð Bjarmason [this message]
2021-03-27  9:50       ` Jeff King
2021-03-28  6:42   ` Junio C Hamano
2021-03-28 17:53     ` Junio C Hamano
2021-04-09 11:49       ` Ævar Arnfjörð Bjarmason
2021-04-10  4:14         ` Junio C Hamano
2021-03-26 11:06 ` [PATCH 0/5] small doc make and lint fixes Jeff King
2021-03-26 15:18   ` Ævar Arnfjörð Bjarmason
2021-03-27  9:48     ` Jeff King
2021-04-09 15:02 ` [PATCH v2 0/7] " Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 1/7] Documentation/Makefile: make $(wildcard howto/*.txt) a var Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 2/7] Documentation/Makefile: make doc.dep dependencies a variable again Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 3/7] doc lint: Perl "strict" and "warnings" in lint-gitlink.perl Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 4/7] doc lint: fix bugs in, simplify and improve lint script Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 5/7] doc lint: lint and fix missing "GIT" end sections Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 6/7] doc lint: lint relative section order Ævar Arnfjörð Bjarmason
2021-04-09 15:02   ` [PATCH v2 7/7] docs: fix linting issues due to incorrect " Ævar Arnfjörð Bjarmason

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=87pmzmnd5h.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.