On Mon, Feb 01, 2021 at 02:08:50PM -0800, Junio C Hamano wrote:

Emily Shaffer [off-list ref] writes:

quoted

Because all but 'post-commit' hooks are expected to make some state
change, force all but 'post-commit' hook to run in series.

OK.  And a sequence of hooks that run in series are expected to use
the output from the previous one as its input?

Kind of, but phrasing it that way is a little odd (to me). The commit
hooks take as input the path to a tempfile which holds the proposed
commit message, and they modify the contents of that file. They don't
make output via stdout or receive the commit message via stdin. Most
hooks work this way, I think with the sole exception of 'proc-receive',
which is implemented weirdly (I said more about it when you asked about
it in your part I review, here:
https://lore.kernel.org/git/YEkgWDthF7sObtAt@google.com (local)).

I'm not sure how to phrase it better. If I were writing a hook I imagine
the combination of taking a filename as an argument and the note about
not running these hooks in parallel would be pretty self-evident. Hmmm.
Maybe instead of the copy/pasted warning about "will not be
parallelized" I could write:

  Hooks executed during prepare-commit-msg will not be parallelized,
  because the file provided in the first argument is expected to be edited
  by each hook.

quoted

'post-commit'
"is meant primarily for notification, and cannot affect the outcome of
`git commit`," so it is fine to run in parallel.

Makes sense.