Re: [RFC PATCH v2 2/2] hook: remote-suggested hooks
- From
- Jonathan Tan <jonathantanmy@google.com>
- Date
- Jul 27, 2021, 21:39 UTC
- Message-ID
- <20210727213942.2574308-1-jonathantanmy@google.com>
- In-Reply-To
- <xmqqczr4fsso.fsf@gitster.g>
Show 27 quoted lines
> 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.
Show 13 quoted lines
> > 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).