> Emily Shaffer <emilyshaffer@xxxxxxxxxx> 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).
