Re: [RFC PATCH v2 2/2] hook: remote-suggested hooks

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <emilyshaffer@google.com> writes:

> I think this is a pretty important point. To me, the ideal flow looks
> like this:
>
>  - I clone some repo, planning to just use the source code. I ignore the
>    hook prompt.
>  - I notice some bug which is within my power to fix. I have forgotten
>    about the hook prompt, because I was having so much fun using the
>    source code in the repo.
>  - I 'git commit' - and 'git commit' says, "Did you know this repo
>    suggests installing a commit-msg hook? You can install it by running
>    'git hook install pre-commit' and run it by running 'git commit
>    --amend --no-edit'. You can audit the commit-msg hook by running 'git
>    hook magic-audit-command-name-tbd'. You can hide this advice <typical
>    advice-hiding advice here>."

Devil's advocate in me says that delaying this until the last
possible moment will make people *not* look at the hook's contents
and just say "yes".  After all, you have been working on a task and
reached one milestone (i.e. you are now ready to say "commit"), and
you want to start recording your thought process before it slips
away from your mind.  To many of us non-multi-tasking types, it is
one of the worst moment to force switching our attention to a
secondary task of vetting project supplied hooks---rather, I'd say
"Oh, I work for project X and if these hooks are supplied by project
X, it is good enough for them, and it must be good enough for me".

> That way I don't add privilege (tell my computer it's OK to execute code
> I didn't look at) until the very possible moment.

So this smells a wishful thinking to me.

> MOTD approach also makes it hard to *update* hooks when the maintainer
> so recommends - would be nice to have something baked in to notice when
> there are new changes to the hooks, so we hopefully don't have
> developers running hook implementations correlating to the date they
> most recently cloned the project.

Interesting.  Every time you run "git commit", the command will
check the existence of remotes/origin/suggested-hooks, compares the
installed .git/hooks/pre-commit with a blob in the tree stored
there, and tells you to update if they are different?  Or perhaps
the installed hooks record from which blob their contents came from,
and perform a three-way content level merge to carry local changes
forward?