list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Tan <>
Cc:,,, Jonathan Tan <>
Subject: Re: [PATCH] hooks: propose repository owner configured hooks
Date: Mon, 21 Jun 2021 12:36:46 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> > Mentioned in [0], 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 [1], it is
a patch or a PR on a branch.


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

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

  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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] hooks: propose repository owner configured hooks' \

* 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:

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