Re: [PATCH] hooks: propose repository owner configured hooks

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 21, 2021, 20:35 UTC
Message-ID: <87eecv2bb8.fsf@evledraar.gmail.com>
In-Reply-To: <20210621193646.1173220-1-jonathantanmy@google.com>

On Mon, Jun 21 2021, Jonathan Tan wrote:

[Most of this I've replied to in https://lore.kernel.org/git/87k0mn2dd3.fsf@evledraar.gmail.com/; or that's a better jump-off point to discuss, just replying to leftover bits here]

Show 7 quoted lines

>> It's also just un-git-y in *requiring* a remote. A .mailmap,
>> .gitattributes etc. all work with a repo you find on-disk, why does
>> config & hooks need to be different?
>
> Why is a remote required? The purpose of this proposal is for remotes to
> suggest hooks, but that doesn't mean that the existing hooks mechanism
> will no longer work.

As a general matter because Git is a distributed VCS, so we should think about how new proposed features can integrate properly with distributed models of development.

If we make distributed development a second-class feature set we're responsible from e.g. guiding open source projects away from distributed repos and patch application etc. to centralized hosting.

We are also talking about exposing users to some manner of "do you trust this thingy?" UI from day 1.

Given the points about training users to accept insecure patterns from others on this topic in past discussions I don't we can just say we'll worry about the distributed aspect later, as that means e.g. someone who interacts with N forks of a repo in GitHub being encouraged to add N trusted remotes if they want their linting of PRs to work properly.

Show 12 quoted lines

>> > This seems like an OK alternative to allow-listing based on remote,
>> > but are you expecting users to add a GPG key to their .gitconfig?
>> 
>> That instead of saying you trust https://github.com/git/git your primary
>> means of interaction with this feature would be saying you, as an
>> example, trust Junio's GPG key.
>
> I think this feature can be extended to trusting GPG keys later. Do you
> think that we should move to a model of trusting a key *instead of* (not
> "in addition to") a URL?
>
> [snip until summary paragraph]

I think we should trust content, GPG keys are one way of getting there. But even a magic URL implementation can be based on trusting advertised content with what I'd think are fairly small changes. E.g. you'd clone a branch, it has hooks, you'd diff the relevant thing against your trusted remote's version, it's the same it passes.