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

[Jonathan Tan <jonathantanmy@google.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".

I think both "I want to vet" and "good enough for project X is good
enough for me" are both reasonable points of view, and this
remote-suggested hook scheme supports both.

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

We do notice when there are new changes, but only during fetch. 

I don't think we should compare the installed .git/hooks/pre-commit with
remotes/origin/suggested-hooks (since the user may have locally modified
that hook), so a solution involving storing the OID of the installed
hook somewhere (I haven't figured out where, though) and comparing that
OID against remotes/origin/suggested-hooks would be reasonable and would
be compatible with the current approach (as opposed to the one which
Ævar describes which, if I understand it correctly, would require
"commit" to access the network to figure out if the hook the client has
is the latest one).