Symlinking git hooks causing unexpected behaviour

[malinin01]

Thank you for a great repo guys, it helps me really a lot to organise all the dotfiles stuff!

There is a potential implicit issue/risk covers in symlinking hooks.

Description:

Let's say you have such scenario:

• git clone project-a
• git clone project-b
• cd project-a
• composer install // additionally installs f.e. post-commit hook

This will most probably break project-b by modifying the project hooks and additionally will modify template hooks in the root dotfiles folder.

In such a scenario composer changes post-commit hook in the project-a which following the links chain, leads to the changes in project-b/.git/hooks/post-commit as well as ~/dotfiles/git_template/hooks/post-commit, since post-commit in project-a is just a link to the initial file.

It's quite common that some tool like composer may change hooks, which leads to such implicit scenario if hooks were symlinked.

Possible solution:

git_template/hooks should be copied and not symlinked

[geoffharcourt]

I'm a bit confused. When I clone a git project, the files from git_template are copied, so changes made from that folder don't go back and pollute the hooks in ~/.git_template, which is symlinked to my ~/dotfiles directory. Does composer install go and edit files outside the project such as the home directory's git template? If so, that seems like a risk inherent to composer and not an issue with dotfiles.

[malinin01]

@geoffharcourt no, composer install doesn't edit anything outside the project. The issue I have reported at that point is when files are symlinked (default mode when running rcup). At this point if you have lets say post-commit hook then ~/git_template/post-commit -> dotfiles/git_template/post-commit. Afterwards you clone or init any project which has tools like husky or compose-git-hooks that modify git hooks. So you should take in account that when cloning or init git project, it also copied ~/git_template/post-commit -> dotfiles/git_template/post-commit and then when such a git hook tool writes to the hook file it replaces content of each hook which was ever symlinked. Quite dangerous outcome 😳

But you're right, using rcup -C solves this issue.

[croaky]

I ran into the same (or similar) problem while working with Git LFS. I ended up deleting the Git hooks directory from my dotfiles (which were originally based on thoughtbot/dotfiles): croaky/laptop@1c96034

I had previously deleted the majority of what was in the Git hooks directory, which was ctags-related for Vim, because my jump-to-definition etc. is now handled by LSP tools such as tsserver for TypeScript. croaky/laptop@02c439b