On Mon, Feb 01, 2021 at 02:08:50PM -0800, Junio C Hamano wrote: > > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > 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@xxxxxxxxxx). 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. > > > '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. >
