On Fri, Dec 13, 2019 at 01:47:27PM -0800, Junio C Hamano wrote:

Emily Shaffer [off-list ref] writes:

quoted

+	/*
+	 * Doesn't look like there is a list of all possible hooks; so below is
+	 * a transcription of `git help hook`.
+	 */

We probably would want to employ technique similar to what you used
for the list of safe configuration we saw in an earlier patch in the
series.  What's not even documented is not worth reporting ;-)

I somewhat slightly would rather not, since I hope to include a list of
the available hooks in my work with git-hook:
https://lore.kernel.org/20191211205114.GD107889@google.com (local)

It's true that the way this patch is written now is prone to bitrot.
It's also true that I could win the lottery tomorrow and never finish my
hopes of git-hook implementation. And it's finally true that I don't
want to write a fourth build-time-generated header which scrapes docs,
especially if I also plan to delete it two months from now.

I wonder whether a better approach might be to drop hook support
entirely here, and add it later on when this particular bit of tech debt
(no canonical list of hook names) is solved, one way or another.

Another approach may be to just list all contents of $(core.hookdir)/
which doesn't end in ".sample", which is what the bash first attempt of
bugreport did. This does mean that those who have something like:

  .git/hooks/
    pre-commit
    pre-commit.d/

  pre-commit:
    sh pre-commit.d/a
    sh pre-commit.d/b

will have their multihook config exposed, although the contents of those
hooks won't be.

I'm interested to know everyone else's opinion, because mine is biased
by my hope that I can solve all the world's problems with git-hook ;)

 - Emily