On Mon, Mar 05 2018, Lars Schneider jotted: >> On 03 Mar 2018, at 11:39, Jeff King <peff@xxxxxxxx> wrote: >> >> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote: >> >>> As in past years, I plan to run it like an unconference. Attendees are >>> expected to bring topics for group discussion. Short presentations are >>> also welcome. We'll put the topics on a whiteboard in the morning, and >>> pick whichever ones people are interested in. >>> >>> Feel free to reply to this thread if you want to make plans or discuss >>> any proposed topics before the summit. Input or questions from >>> non-attendees is welcome here. >> >> I'll plan to offer two topics: >> >> - a round-up of the current state and past year's activities of Git as >> a member project of Software Freedom Conservancy >> >> - some updates on the state of the git-scm.com since my report last >> year >> >> As with last year, I'll try to send a written report to the list for >> those who aren't at the summit in person. > > Thanks for starting this. I would like to propose the following topics: > > - hooks: Discuss a proposal for multiple local Git hooks of the same type. I'm assuming you mean having stuff like pre-receive.d/* in addition to pre-receive: I had a WIP series for this that I didn't end up pursuing after getting discouraged at: https://public-inbox.org/git/CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@xxxxxxxxxxxxxx/ There's various bolt-on solutions that do this for subsets of the hooks, e.g. GitLab now has this at https://docs.gitlab.com/ee/administration/custom_hooks.html and this stand-alone solution: https://gist.github.com/carlos-jenkins/89da9dcf9e0d528ac978311938aade43 I still think this would be great to have, but Junio's objection being: > Junio: And I have to say that a sequential execution that always > Junio: short-circuits at the first failure is below that threshold. > Junio: > Junio: One reason I care about allowing the users to specify "do not > Junio: shortcut" is that I anticipate that people would want to have a > Junio: logging of the result at the end of the chain. Got me discouraged, it would have made the implementation a bit more complex, and I found other solutions to the problem I was trying to solve. Now we use Gitlab's implementation of this which has the semantics I proposed at the time, and you just put log hooks at the beginning, but of course that's server-side only. Having this be generally usable in git would be great.
