On Fri, Dec 13, 2019 at 01:47:27PM -0800, Junio C Hamano wrote: > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > + /* > > + * 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@xxxxxxxxxx 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
