git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: albertqcui@gmail.com, gitgitgadget@gmail.com, git@vger.kernel.org
Subject: Re: [PATCH] hooks: propose repository owner configured hooks
Date: Mon, 21 Jun 2021 22:35:04 +0200	[thread overview]
Message-ID: <87eecv2bb8.fsf@evledraar.gmail.com> (raw)
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]

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

  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 \
    --in-reply-to=87eecv2bb8.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=albertqcui@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.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).