This sounds like a really cool idea -- and I think the latest updates which add commit-msg hooks could support this idea.

The concerns I have about this:

• What about --no-verify?
  • Neither .git/hooks/pre-commit nor .git/hooks/commit-msg run when --no-verify is passed, so nothing happens
• What about SKIP?
  • This could be detected by a cli and adjust the number of hooks
• What about hooks that don't affect any files?
  • I'd still consider these hooks to have "run", but trivially -- it'd be quite difficult to figure out which ones were applicable without replicating the entire logic of pre-commit in a hook
• How would a client hook know if all the hooks passed?
  • Simply put, it wouldn't but I don't think that's actually a problem -- in the case of pre-commit hooks failing, it would never get to the commit-msg hook which does the modification.
  • When another commit-msg hook fails, even if the hook has done the modification to the commit message the commit would still get properly cancelled

If you don't mind, I'm going to create another repository and start hacking away on this idea -- I think this is a good one :)

For a first pass, I'm just going to hardcode a message -- we can work on making it fancier in the future if that's desirable :)

👍 Makes sense.

Just an update on this, I am still working on it though I've put this more on the back burner. Due to the tight coupling between pre-commit and this hook I think it makes more sense to keep this internal to the framework. So now I'm mostly stuck on how to enable such a thing -- I have a hunch I'll want to do something with #414

A framework for adding something like this was contributed as part of #643