Re: [PATCH v3 5/9] hook: mark non-parallelizable hooks

[Junio C Hamano <gitster@pobox.com>]

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

>  hook.jobs::
>  	Specifies how many hooks can be run simultaneously during parallelized
>  	hook execution. If unspecified, defaults to 1 (serial execution).
> +	Some hooks always run sequentially regardless of this setting because
> +	git knows they cannot safely be parallelized: `applypatch-msg`,
> +	`pre-commit`, `prepare-commit-msg`, `commit-msg`, `post-commit`,
> +	`post-checkout`, and `push-to-checkout`.

If there is a simple rule that can be used to decide hooks with what
characteristics can and cannot be run in parallel, near the "because
git knows" sentence is where we want to write it down.  It would
help new developers decide if their newly invented hook should be
forced serial execution.

For example, applypatch-msg is given a file and is allowed to modify
the file (perhaps reformat or typofix), so two of them competing to
edit that single file would be a nonsense.  Letting them edit the
file one after the other would make much more sense.  So one of the
rules may be "a hook that is given a file and expected to edit it".
other two hooks with -msg suffix may fall into the same category.
What are the rules behind the decision for others?  Are they also
explained with simple rules?