Re: Contributor Summit planning

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 5, 2018, 21:57 UTC
Message-ID: <877eqqnq22.fsf@evledraar.gmail.com>
In-Reply-To: <CD80986F-E79B-4588-AB0F-AD5C6385836D@gmail.com>

On Mon, Mar 05 2018, Lars Schneider jotted:

Show 27 quoted lines

>> On 03 Mar 2018, at 11:39, Jeff King <peff@peff.net> 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@mail.gmail.com/

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:

Show 6 quoted lines

> 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.