Emily Shaffer [off-list ref] 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?
Emily Shaffer [off-list ref] writes:
quoted
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.
quoted
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).