From: Adrian Ratiu Date: Sun, 22 Feb 2026 00:39:04 GMT Subject: Re: [PATCH v2 0/8] Specify hooks via configs Message-ID: <87ikbpwr13.fsf@collabora.com> In-Reply-To: <87o6liw4s1.fsf@collabora.com> On Sat, 21 Feb 2026, Adrian Ratiu wrote: > On Fri, 20 Feb 2026, "brian m. carlson" wrote: >> On 2026-02-18 at 22:23:44, Adrian Ratiu wrote: >>> Hello everyone, >>> >>> v2 addresses all feedback received in v1. >>> >>> This series adds a new feature: the ability to specify commands to run >>> for hook events via config entries (including shell commands). >>> >>> So instead of dropping a shell script or a custom program in .git/hooks >>> you can now tell git via config files to run a program or shell script >>> (can be specified directly in the config) when you run hook "foo". >>> >>> This also means you can setup global hooks to run in multiple repos via >>> global configs and there's an option to disable them if necessary. >>> >>> For simplicity, because this series is becoming rather big, hooks are >>> still executed sequentially (.jobs == 1). Parallel execution is added >>> in another patch series. >> >> I'm interested in how you plan to make parallel execution work >> gracefully. >> >> We've already established that it's necessary to preserve stdout and >> stderr (including wiring them up to the TTY) so as to not break >> existing, widely deployed hooks, such as those in Git LFS. That means >> that to get parallel execution where the hooks don't write over each >> other's output and fight for the terminal, you'd need to multiplex each >> one, including providing a PTY if the appropriate descriptor already has >> a terminal, such that the output is at the very least handled line by >> line and ideally batched into per-hook chunks. Is that the plan, or do >> you plan to do it differently? >> >> I ask because situations where the hook output is not handled gracefully >> and hooks fight over output or where the existence of TTY on a file >> descriptor is not preserved will result in bug reports and broken tests >> for tools that use Git, which I think we'd all like to avoid. > > Hi Brian, > > Yes, this is all done already. Phillip Wood actually brought this TTY > issue up in his review of the v1 parallel hooks series (many thanks). :) > > >> Of course, that's not in this series, so it may not even be written yet, >> but if it's not, then this is something to keep in mind for when it gets >> submitted. > > Yes, that's a separate series [1] and I'm about to send v2 very soon. > > Please review v2 directly when I send it because it will contain > significant changes from v1. v1 is not worth reviewing at this point. > > To give you a high level description: > > All hooks continue to run sequentially (serialized) by default, just > like before. > > To run some of the hooks in parallel, I had to introduce an extension, > because we need to break backwards compatibility by combining stdout and > stderr and piping them through run-command's muxer, detached from the > terminal. There is only 1 known hook requiring this extension (pre-push) > but it's trivial to add more, if necessary. > > Patrick's idea is to leave it up to the user to decide what to > parallelize, because the user knows if their hooks are safe or not (eg > if they write the same file or call the same program), or if it's ok the > enable the extension or not. > > Some hooks are known never to be safe to parallelize, in that case git > will always enforce serial execution. > > Please wait for v2 of that series, it's my top priority to get it out, > Adrian > > 1: > https://lore.kernel.org/git/20260204173328.1601807-1-adrian.ratiu@collabora.com/n Hi again Brian, v2 of the parallel series is out if you want to review it: https://lore.kernel.org/git/20260222002904.1879356-1-adrian.ratiu@collabora.com/T/#u P.S. I think your spam filter is blocking all my e-mails? I get this reply from you: sandals@crustytoothpaste.net, ERROR CODE :554 - 5.7.1 : Client host rejected: CONN:SPAM Original-Recipient: rfc822; sandals@crustytoothpaste.net Final-Recipient: rfc822; sandals@crustytoothpaste.net Status: 554 Action: failed Last-Attempt-Date: 22 Feb 2026 00:30:10 GMT Diagnostic-Code: 5.7.1 : Client host rejected: CONN:SPAM Remote-MTA: dns; complex.crustytoothpaste.net