Re: Contributor Summit planning
- Date: Mon, 05 Mar 2018 22:57:41 +0100
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: Contributor Summit planning
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
>> 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
I had a WIP series for this that I didn't end up pursuing after getting
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
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: 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
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.