git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Albert Cui <albertqcui@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: "Albert Cui via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Emily Shaffer" <emilyshaffer@google.com>,
	"Derrick Stolee" <stolee@gmail.com>,
	emaste@freebsd.org
Subject: Re: [PATCH v4] hooks: propose project configured hooks
Date: Thu, 3 Jun 2021 13:16:20 -0700	[thread overview]
Message-ID: <CAMbkP-Qkd0EzNvhKLeOU3LCdTDiYKpTmZJqMN5rFDg-WkVMrAw@mail.gmail.com> (raw)
In-Reply-To: <20210603033142.353066-1-jonathantanmy@google.com>

On Wed, Jun 2, 2021 at 8:31 PM Jonathan Tan <jonathantanmy@google.com> wrote:
>
> > +* After clone, repository suggests hooks to the user
> > +
> > +    ** User receives a non-interactive message advertising hooks available to
> > +    install
> > +
> > +    ** User can see what hooks and commands are being suggested and from what
> > +    remote.
>
> From the implementation point of view, would it be sufficient to just
> advertise that hooks are available? Assuming that the hooks will be
> available from a specially named ref (as stated below), then we would
> only need to inform the user that this ref exists and hooks can be
> inspected using a special command. Likewise for when we fetch and notice
> that the ref now points to a different object. Then, we wouldn't need to
> do any extra fetching upon clone/fetch, saving time and bandwidth, but
> just do so if the user requests it.
>

From a user perspective, I think it's better to not just tell users
that hooks are available but also /what/ hooks are available.

That said, that doesn't require getting everything from the ref as the
hook command itself might be stored in this ref. So something like
this seems sufficient to me: "Origin suggests setting up a `pre-push`
hook which runs `pre_push.sh`. To view the contents of `pre_push.sh`,
run {special command}."

> > +Feature Requirements
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +Minimum Feature Set
> > +^^^^^^^^^^^^^^^^^^^
>
> [snip]
>
> > +* The configuration specifies where the hook commands reside
> > +
> > +    ** This could be a path to a script/binary within the repository
> > +
> > +    ** This could be a path to a script/binary contained within submodules of
> > +    the repository
> > +
> > +    ** This could be a user installed command or script/binary that exists
> > +    outside of the repository and is present in `$PATH`
>
> Right now hooks are fixed files (well, not counting Emily Shaffer's work
> on config hooks). Would it be sufficient to just provide replacements
> for those files?
>

My thought was we'd leverage config hooks and basically write to the
config for setting up hooks.

> > +* The configuration lives outside the worktree.
> > +
> > +    ** Allows updated hooks to apply across history and branches, reducing
> > +    the maintenance burden of keeping hooks updated.
> > +
> > +    ** Allows different remotes to specify different configuration. This is
> > +    useful for public vs private central repositories or for repositories which
> > +    support different Git functionality.
>
> Hmm...what would be a use case of this? And how would, say, a pre-commit
> hook know which remote it is for?
>

For a concrete example, we use Gerrit for internal reviews and need
the Change-Id hook, but we don't want that when upstreaming.

Good question for specifying remotes. This might imply the need for
something like `git commit --hooks-from=origin`.

> > +* The user receives advice to install hooks.
> > +
> > +    ** The advice should clearly indicate the suggested hook command(s) and hook
> > +    event(s) as well as the central repository that is suggesting them (via
> > +    remote URL).
> > +
> > +    ** The user should be able to use configuration to turn off this advice.
> > +
> > +    ** The advice should appear at the following times:
> > +
> > +        *** After a clone
> > +
> > +        *** After a suggested hook would have run if not already installed. The
> > +        advice should include commands for installing the hook and invoking it.
> > +        For example, for a hook on 'git commit', the user should receive advice
> > +        to amend their commit after hook installation.
>
> This seems contradictory to a point above where we only inform the user
> upon clone (when the user is in the setup mood).
>

Good catch, I should clarify that previous point. The main concern is
prompting before a hook will execute which would get in the way of
existing workflows, making users susceptible to blindly agreeing.
Showing advice after the fact doesn't get in the way, and this is one
reason why "advice" felt like the right terminology to use (more
below): it's merely a helpful message that a user can optionally
choose to follow.

> > +* If, after fetch, the central repository suggests new or updated hooks, the
> > +user should receive advice to install these new hooks (note: implementation
> > +should not interfere with requirement listed in“Fast Follows")
>
> In Git, the term "advice" seems to be used more for extra
> explanations that you can turn off once you're experienced with Git.
> Here, these seem like things that we would want to notify users about
> regardless of experience level, so maybe the word "notification" is more
> appropriate.
>

Another reason to use "advice" here is because the existing system
allows users to turn off the advice when it's not needed for the
requirement: "The user should be able to use configuration to turn off
this advice."

Do advice settings work on a per-clone basis? If not, I agree "advice"
is probably not the right term.

> > +* Works across Windows/Linux/macOS
> > +
> > +Fast Follows
> > +^^^^^^^^^^^^
> > +
> > +* Behind configuration, a user can opt to automatically install hook updates
> > +from a given remote.
> > +
> > +* Allow users to make trust decisions based on GPG signing e.g. if the
> > +configuration came from a signed commit, the signature could be shown along
> > +with the remote it came from.
>
> For the MVP, do we need this?
>
No, that's what I meant by "Fast Follows" -- not needed for the initial feature.

  reply	other threads:[~2021-06-03 20:17 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
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 [this message]
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-Qkd0EzNvhKLeOU3LCdTDiYKpTmZJqMN5rFDg-WkVMrAw@mail.gmail.com \
    --to=albertqcui@gmail.com \
    --cc=avarab@gmail.com \
    --cc=emaste@freebsd.org \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=stolee@gmail.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).