git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Albert Cui <albertqcui@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Albert Cui via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] hooks: propose repository owner configured hooks
Date: Thu, 18 Mar 2021 16:45:01 -0700	[thread overview]
Message-ID: <CAMbkP-SNXbpd3OeBP9uqrLj-WnYXWhD89RqQv3SnzQaZ96rO5Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqim5oqen4.fsf@gitster.g>

On Thu, Mar 18, 2021 at 3:29 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> So avoid "repository owner configured", when you mean "project
> configured" or "project controlled".
>
> On the other side of the coin is that this document should avoid
> reference to a "repository" in an ambiguous way, as it can refer to
> the central meeting place the project controls, lets developers to
> clone and fetch from, and push into, and it can also refer to the
> copy of that central meeting place individual contributors work in.
>
> In our own documentation, we often refer to the former as "the
> central repository", and the latter as "a clone" (as in "you start
> working in your own clone").
>

Ack, thanks for the correct terminology.

> > +* The `pre-commit` hook event: before committing, a developer may want to lint
> > +their changes to enforce certain code style and quality. If there are style
> > +issues, the developer may want the commit to fail so that they can fix the
> > +issues.
>
> This is irrelevant in the context of this proposal, no?  It is not
> that "the developer may want".
>
> Rather, it is "the project may want the commit to fail so that they
> won't upload commits that violate the house style", no?

Good point

> > +User Goals / Critical User Journeys
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +* As a repository owner / project maintainer,
> > +
> > +    ** I want to prevent leaks / share code widely so I check that developers
> > +    are uploading code to the right place.
>
> I understand "You want to prevent leaks", but not "I want to share
> code widely".  Perhaps you meant s/widely/narrowly/?
>

There are two opposite intentions here and the slash is making it confusing.
Some projects have internal and external central repositories, and they want to
encourage developers to push to the external repositories when possible.

> > +Design Principles
> > +~~~~~~~~~~~~~~~~~
> >
> > +* *Treat hooks as software, not configuration:* We take seriously the
> > +responsibility that comes with causing arbitrary code to run on a user's
> > +machine. Such code needs to come from a reputable source, be automatically
> > +updated, and run with user consent.

> > +Feature Requirements
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +Minimum Feature Set
> > +^^^^^^^^^^^^^^^^^^^
> > +    * Users do not need to run setup scripts to install hooks --- the setup flow
> > +    happens automatically at clone time
>
> This one is probably unacceptable, as it makes it impossible to
> perform unattended cloning.  A better alternative may be to make it
> part of the build procedure.
>
> > +* Automation is able to continue to use clone and other commands
> > +non-interactively
>
> This directly contradicts with the "setup flow happens
> automatically", doesn't it?  The user can pretend to be (or the
> "automation" detection may incorrectly misidentify the users to be)
> an automated client when cloning the project, and would not trigger
> any setup.  A separate setup procedure needs to be there to salvage
> such users anyway.

I don't think there's a contradiction here. Users should always be able to
decline hooks since it's their own machine, so the goal shouldn't be to prevent
uses from declining setup.

That said, most users want to do the right thing so that their patches
get accepted
e.g. adopt the right code styles via linting, so the goal should be to
make it as easy
as possible for them to do that.

In the ideal case: automation detection is great and there are few
false positives :)

If not, we can't break unattended clones, so the default clone
behavior would always have
to be no-hooks-setup... maybe that speaks to `git clone --recommended-setup`?

+1 we'd need a method for a user to trigger a set up if they change
their minds or
need to recover.

> > +* Works across Windows/Linux/macOS
> > +
> > +Fast Follows
> > +^^^^^^^^^^^^
> > +
> > +* When prompted to execute a hook, users can specify always or never, even if
> > +the hook updates
>
> This contradicts the earlier claim to take the responsibility
> seriously, doesn't it?  I think the convenience feature is useful,
> but then we should tone down the claim---we allow users to be loose
> and blindly trust their own project, instead of taking it always
> seriously.
>

I don't think this is contradicting since the user is consenting, but
maybe the principle
can be clearer:

"Execution of code must require user consent, and users should clearly
understand
what they are consenting to." That is, I would imagine for a prompt
for "always" we'd

1) have clear help text saying that hooks from $REMOTE will be
automatically installed
when they change
2) give an FYI if hooks the hooks do change

  reply	other threads:[~2021-03-18 23:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 22:03 [PATCH] hooks: propose repository owner configured hooks Albert Cui via GitGitGadget
2021-03-18 22:29 ` Junio C Hamano
2021-03-18 23:45   ` Albert Cui [this message]
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
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=CAMbkP-SNXbpd3OeBP9uqrLj-WnYXWhD89RqQv3SnzQaZ96rO5Q@mail.gmail.com \
    --to=albertqcui@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).