From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Jonathan Tan <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH] hooks: propose repository owner configured hooks Date: Mon, 21 Jun 2021 22:35:04 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Mon, Jun 21 2021, Jonathan Tan wrote: [Most of this I've replied to in https://firstname.lastname@example.org/; or that's a better jump-off point to discuss, just replying to leftover bits here] >> 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. >> > 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.
next prev parent reply other threads:[~2021-06-21 20:49 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-18 22:03 Albert Cui via GitGitGadget 2021-03-18 22:29 ` Junio C Hamano 2021-03-18 23:45 ` Albert Cui 2021-03-19 1:28 ` brian m. carlson 2021-03-19 10:27 ` Ævar Arnfjörð Bjarmason 2021-04-06 0:35 ` Albert Cui 2021-04-07 22:47 ` Ævar Arnfjörð Bjarmason 2021-06-21 19:36 ` Jonathan Tan 2021-06-21 20:35 ` Ævar Arnfjörð Bjarmason [this message] 2021-03-26 1:43 ` [PATCH v2] hooks: propose project " Albert Cui via GitGitGadget 2021-03-29 23:20 ` Emily Shaffer 2021-04-01 20:02 ` Albert Cui 2021-03-30 15:24 ` Derrick Stolee 2021-04-05 22:45 ` Albert Cui 2021-04-05 23:09 ` Junio C Hamano 2021-04-05 23:40 ` Albert Cui 2021-04-06 0:13 ` Junio C Hamano 2021-04-06 0:27 ` Albert Cui 2021-04-06 23:15 ` brian m. carlson 2021-04-07 7:53 ` Ævar Arnfjörð Bjarmason 2021-04-07 13:09 ` Derrick Stolee 2021-04-07 18:40 ` Albert Cui 2021-04-07 20:02 ` Junio C Hamano 2021-04-07 22:23 ` Ævar Arnfjörð Bjarmason 2021-04-15 16:52 ` Ed Maste 2021-04-15 19:41 ` Junio C Hamano 2021-04-15 20:37 ` Ed Maste 2021-04-15 20:50 ` Junio C Hamano 2021-04-15 22:28 ` brian m. carlson 2021-04-02 9:59 ` Ævar Arnfjörð Bjarmason 2021-04-05 23:42 ` Albert Cui 2021-04-02 10:30 ` Ævar Arnfjörð Bjarmason 2021-04-03 0:58 ` Albert Cui 2021-04-24 1:38 ` [PATCH v3] " Albert Cui via GitGitGadget 2021-04-28 2:48 ` Junio C Hamano 2021-05-05 19:11 ` [PATCH v4] " Albert Cui via GitGitGadget 2021-06-03 3:31 ` Jonathan Tan 2021-06-03 20:16 ` Albert Cui 2021-06-03 22:10 ` Jonathan Tan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] hooks: propose repository owner configured hooks' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).