git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 6/7] config: allow configuration of multiple hook error behavior

From
Jeff King <peff@peff.net>
Date
May 16, 2019, 05:08 UTC
Message-ID
<20190516050835.GA7723@sigill.intra.peff.net>
In-Reply-To
<20190515231017.GM7458@genre.crustytoothpaste.net>
On Wed, May 15, 2019 at 11:10:17PM +0000, brian m. carlson wrote:
Show 5 quoted lines
> > An alternative name is onError, probably more often used for event
> > callbacks. But I don't know, maybe errorBehavior is actually better.
> 
> I'm going to use "errorStrategy", since we already have
> submodule.alternateErrorStrategy.

That sounds good (and I don't care too much about the name as long as it it is in the per-hook subsection like this).

> > should we fall back to hook.errorBehavior? That allows people to set
> > global policy, then customize just a small set of weird hooks.
> 
> Sure, that sounds good.
I like this, too.
Show 16 quoted lines
> > maybe stop-on-first-error (or if you go with the "onError" name, I
> > think "stop" is enough). I know "stop on/after first hook" does not
> > really make any sense when you think about it. Maybe stop-on-first is
> > sufficient.
> > 
> > I was going to suggest strcasecmp. But core.whitespace (also has
> > multiple-word-values) already sets a precedent on strcmp. I think
> > we're good. Or mostly good, I don't know, we still accept False, false
> > and FALSE.
> 
> I think with errorStrategy, "stop" is fine. Simpler is better.
> 
> I literally picked what Peff had suggested in his email (mostly because
> I'm terrible at naming things), and I don't get the impression he spent
> a great deal of time analyzing the ins and outs of the names before
> sending. I could be wrong, though.

No, I didn't. :) I think "stop" is good. If the others are report-any-error and report-any-success, then the matching name for this could be report-first-error.

Show 7 quoted lines
> > > +               else if (!strcmp(value, "report-any-error"))
> > 
> > I couldn't guess based on this name alone, whether we continue or stop
> > after the reporting part. The 7/7 document makes it clear though. So
> > all good.
> 
> I'm open to hearing better suggestions if anyone has any.

Maybe report-all-errors would indicate that it was going to run all of the hooks. I dunno. I think the documentation you wrote is plenty clear with the current name.

-Peff
Previous: brian m. carlsonNext: Jeff King
Message 22 of 34 in “Multiple hook support”
  1. 0/7 Multiple hook supportbrian m. carlson, May 14, 2019
  2. 1/7 run-command: add preliminary support for multiple hooksbrian m. carlson, May 14, 2019
  3. Duy NguyenMay 14, 2019
  4. brian m. carlsonMay 15, 2019
  5. brian m. carlsonMay 29, 2019
  6. Johannes SchindelinMay 14, 2019
  7. brian m. carlsonMay 15, 2019
  8. Johannes SixtMay 16, 2019
  9. Johannes SchindelinMay 17, 2019
  10. 2/7 builtin/receive-pack: add support for multiple hooksbrian m. carlson, May 14, 2019
  11. 3/7 rebase: add support for multiple hooksbrian m. carlson, May 14, 2019
  12. Duy NguyenMay 14, 2019
  13. Johannes SixtMay 14, 2019
  14. brian m. carlsonMay 15, 2019
  15. Duy NguyenMay 16, 2019
  16. 3/7 sequencer: add support for multiple hooksbrian m. carlson, May 14, 2019
  17. 4/7 builtin/worktree: add support for multiple post-checkout hooksbrian m. carlson, May 14, 2019
  18. 5/7 transport: add support for multiple pre-push hooksbrian m. carlson, May 14, 2019
  19. 6/7 config: allow configuration of multiple hook error behaviorbrian m. carlson, May 14, 2019
  20. Duy NguyenMay 14, 2019
  21. brian m. carlsonMay 15, 2019
  22. Jeff KingMay 16, 2019
  23. Jeff KingMay 16, 2019
  24. brian m. carlsonMay 16, 2019
  25. Jeff KingMay 16, 2019
  26. 7/7 docs: document multiple hooksbrian m. carlson, May 14, 2019
  27. Duy NguyenMay 14, 2019
  28. Jonathan NiederMay 14, 2019
  29. brian m. carlsonMay 14, 2019
  30. Jonathan NiederMay 14, 2019
  31. brian m. carlsonMay 16, 2019
  32. Jonathan NiederMay 16, 2019
  33. Jeff KingMay 16, 2019
  34. Duy NguyenMay 14, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.