30 ms·

curl https://.../hook.sh > .git/hooks/pre-commit This seems like a bad idea, since you may already have a commit hook that this would clobber. Does anyone use

by web007 10y ago

curl https://.../hook.sh > .git/hooks/pre-commit This seems like a bad idea, since you may already have a commit hook that this would clobber. Does anyone use any kind of plugin manager for git hooks? I know I can just build a shellscript (and have done so extensively) but is there something like pathogen / npm / bundler for a pluggable git hook architecture? https://github.com/brigade/overcommit https://github.com/brigade/overcommit seems to be an option, anyone have experience with that?

delinka 10y ago
curl ... >> .git/hooks/pre-commit Append instead
- avar 10y ago
  That's horrible advice. The existing .git/hooks/pre-commit may not even be a shellscript, you could be appending to a binary file. Even if it's a shellscript you can't just concatenate shellscripts together and expect them to work as thought you'd run them as two independent shellscripts.
  - delinka 10y ago
    Presumably, one's git hooks are not in danger of being lost to oblivion. If that's the case, neither bit of advice is ideal. If, however, one is careless enough that unix plumbing with obliterate the hook for eternity, then appending at least allows the original to exist some place.
spenuke 10y ago
It's hard to completely generalize for the clobbering reason you point out. Assuming that you essentially want to keep your hooks coupled with your source code (or, at least, it's ok to do so), I've found that Make works pretty well here. In the root of the project directory, you have a subdirectory containing all the hooks you need (or use a git submodule), and then you create a Make target to copy those hooks (and make them executable) to your .git/hooks directory. Make is nice because it won't clobber existing ones (unless they are older, in which case you probably want them overwritten). Then, whenever someone first clones the repo (or whenever you make a change to the hooks), they just need to run make on that target again. Obviously, not an ideal choice for everyone, but it's pretty simple and works well for me.
- deleted 10y ago
  [deleted]
dpcx 10y ago
https://github.com/brigade/overcommit https://github.com/brigade/overcommit It's wonderful.

by web007 10y ago

delinka 10y ago

curl ... >> .git/hooks/pre-commit Append instead

avar 10y ago
That's horrible advice. The existing .git/hooks/pre-commit may not even be a shellscript, you could be appending to a binary file. Even if it's a shellscript you can't just concatenate shellscripts together and expect them to work as thought you'd run them as two independent shellscripts.
- delinka 10y ago
  Presumably, one's git hooks are not in danger of being lost to oblivion. If that's the case, neither bit of advice is ideal. If, however, one is careless enough that unix plumbing with obliterate the hook for eternity, then appending at least allows the original to exist some place.

spenuke 10y ago

It's hard to completely generalize for the clobbering reason you point out. Assuming that you essentially want to keep your hooks coupled with your source code (or, at least, it's ok to do so), I've found that Make works pretty well here. In the root of the project directory, you have a subdirectory containing all the hooks you need (or use a git submodule), and then you create a Make target to copy those hooks (and make them executable) to your .git/hooks directory. Make is nice because it won't clobber existing ones (unless they are older, in which case you probably want them overwritten). Then, whenever someone first clones the repo (or whenever you make a change to the hooks), they just need to run make on that target again. Obviously, not an ideal choice for everyone, but it's pretty simple and works well for me.

deleted 10y ago
[deleted]

dpcx 10y ago

https://github.com/brigade/overcommit https://github.com/brigade/overcommit It's wonderful.