From: Jonathan Tan <email@example.com> To: firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org, email@example.com, Jonathan Tan <firstname.lastname@example.org> Subject: Re: [PATCH] hooks: propose repository owner configured hooks Date: Mon, 21 Jun 2021 12:36:46 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> > > Mentioned in , the primary motivation for a magic config branch > > that lived outside of the worktree was "since the configuration is > > separate from the code base, it allows you to go back in history or to > > older branches while preserving "improvements" to the hooks > > configuration e.g. maybe the project has shifted to using a newer > > version of a linter." > > It also means that your hooks will forever need to be aware of the union > of all revisions in the project to work properly, or more likely they'll > simply break on older revisions as e.g. a hook that needs to handle a > test directory handles just "t", but it used to be called "tests". Yes, but I think that's better than hooks not working when we're operating on past commits for whatever reason. > 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. > How would a user of such a repo suggest changes to a hook? Now it's > fairly easy for e.g. .gitattributes, you change it, push a branch, ask > for it to be merged etc. It depends on the exact implementation, but in my suggestion , it is a patch or a PR on a branch.  https://email@example.com/ > If you want the same hook for all revisions ever having some light logic > in the hook itself to check/cache that (it's executing arbitrary code > after all) seems like a saner thing for those who have this "magic > branch" use-case than to make it the default. If hooks are per-version, this doesn't work for versions before when the hook was introduced. [skipping discussion about general remote-suggested config] > As noted by brian m. carlson etc. in the side-thread in > <YGzrfaSC4xd75j2U@camp.crustytoothpaste.net> the danger is that by > making this a supported feature git becomes the social-engineering > vector to fool users into trusting a command like that which they > otherwise might not have. This danger is being discussed there, and we're trying to balance this danger against the fact that projects need or want functionality like this (as evidenced by the available tools described in the original email). > > 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] > So if I trust Junio's key and would like this to Just Work it would be > better if I clone a mirror of git.git that it works, and I don't have to > maintain a list of all mirrors myself. Trusting based on content and GPG > keys gives you that, magic URLs don't. This seems like scope creep to me - perhaps a GPG key is more flexible than a URL, but I don't think we need this flexibility yet (and we can always add it later).
next prev parent reply other threads:[~2021-06-21 19:36 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 [this message] 2021-06-21 20:35 ` Ævar Arnfjörð Bjarmason 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).