Re: master e54b94c28cd: Use @xref more consistently; "See @ref" -> "@xref"

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 26 Jan 2025 15:22:42 -0600
> Cc: Eli Zaretskii <eliz@gnu.org>, luangruo@yahoo.com, emacs-devel@gnu.org
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> > I did not mean git hooks.  Git *commit* hooks are already over-used by
> > Emacs, and I'm not sure they're useful enough to be set up
> > automatically, without my explicit consent, whenever I run autogen.sh.
> >
> > I'm not saying git hooks are entirely useless, but commit hooks in
> > particular feel like an unwarranted intrusion into my workflow.  I often
> > want to mark a temporary commit with DO NOT COMMIT, but that makes the
> > first line longer than some hook thinks it should be.
> 
> I recommend this `git commit` flag in these cases:
> 
>     -n, --[no-]verify
>         By default, the pre-commit and commit-msg hooks are run. When
>         any of --no-verify or -n is given, these are bypassed. See also
>         githooks(5).

Yes, but it's a nuisance to have a commit fail, and then to try to
recollect or find in the docs the exact name of this option.  (I use
it so infrequently that I succeed to never remember its exact
spelling.)  It makes what should have been a very short action take
several tens of seconds.

> For my part, I think git commit hooks are quite useful to avoid obvious
> mistakes such as trailing whitespace, and I think if we disabled them
> we'd see more of that.

When they don't produce false positives, sure.

> I think we should recommend always running the full test suite on every
> commit before pushing

I think this is impractical: the time needed to run the suite is too
long, even on a fast machine.  In any case, let's start by achieving
the smaller goal of having the test(s) for the file(s) being changed
in a changeset be always run.  Experience shows that this is not
always the case.

> To make that more realistic, `make check` has to be both useful and
> fast.  I think it's getting more and more useful over time (this part
> takes real work), but it doesn't have to be too hard to also make it
> faster.  For example, I've argued in the past that we should be
> proactive with moving slow tests to :expensive, where "slow" is any
> individual test case that takes more than one second to run or so.

I think almost all (if not all) the tests run by default are already
fast enough.  But all of them added together take a significant amount
of time.  And we add tests all the time (and will continue to do so,
since our test coverage is still far from satisfactory).