Hi, On Thu, Jan 16, 2020 at 12:06 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > which makes all the difference. Another example is to compute ctags: > > #!/bin/sh > > ~/bin/hook_ctags.sh >/dev/null 2>&1 & Thought about this ctags case a bit more. In contrast to the deployment cases you brought up (which appear to be protected by a branch check anyway), doesn't this one argue more that post-commit should be run for all rebase types? Sure, it'd take more computation time, but if a user runs "git pull --rebase" and then is frustrated that all their tags are extremely out of date then they may be kind of frustrated. Of course, arguing against myself, we could always tell them to just implement a post-rewrite hook. > Here's a fun one that updates a timesheet: > https://github.com/GokhanArik/git-hooks-timesheet So...cherry-picking commits will pad your timesheet with duplicate work on the same topic (because cherry-pick calls sequencer which calls "git commit"), and so will interactive-based rebases, but rebase-am (the default rebase in the past) wouldn't. Fun indeed... Wouldn't such users view removing the post-commit hook from sequencer as "harmful to their productivity"? And shouldn't we add the post-commit hook to rebase-am in order to "increase their productivity"? ;-) > Sorry for the noise, No, these were great examples; thanks for pointing them out. My commentary about the timesheet is the only thing that is noise here. :-)
