Question: Why are git hooks disabled by default?

[Timeraa]

So far I really enjoy using GitButler but I do always find myself confused as to why git hooks are disabled by default as those ensure consistent stable/linted code.

Is there any reason behind this or am I just using it wrong?

[schacon]

Nope, I think it's reasonable that if the hooks exist and are executable, you expect them to be executed. I think we were hesitant to just run stuff without you knowing we would run stuff, but I think opt-out makes more sense in this case.

[Timeraa]

Maybe you guys should enable this setting in a future update and change it to be enabled by default and letting people know about this change? (Because it's really tedious to enable it for all my projects)

[TGTGamer]

I actually disagree with this change.

Take a tool like trunk.io, an amazing tool which can manage you git hooks, but it still explictictly asks to enable git hooks.

I think turning on by default in a Git Tool like this could lead to confusion with some users, leading to them blaming butler for not working when their hooks might be the thing which is incompatible. There should be an explicit understanding when the hooks are enabled which separates the hook problems from the client.

[Timeraa]

I don't think it would cause issues, I saw GitButler improved how it shows errors from git hooks, they only run if you set them up anyway but if your team uses git hooks and someone uses GitButler and doesn't know that they are off by default they end up committing broken code or unlinted code which in my opinion causes more issues.

I think when you first import it there should be an option which is checked by default giving the user the choice.

[TGTGamer]

If your team uses git hooks and someone uses GitButler and doesn't know that they are off by default

This is where my point about things breaking comes from though, I could say the reverse. Some of my team, don't understand how Git Hooks work - not fully at least - and on a few occasions when something has gone wrong, I've had users come to me with "My VSCode is broken" and it turns out to be a hook isn't playing nice and isn't well displayed to the user.

---

I think the key takeaway is:

Whichever way the default hooks toggle is set - it needs to be displayed to the user when initialising a project

So maybe the solution here is to add a UI element to the initialisation page asking if the user wants the hooks, then add option in a configuration file for centrally managing it.

[Qix-]

@schacon VSCode prompts "do you trust this repository" when you open it. We could replicate that, then store a local gitbutler.trusted=1 config value.

[jhnns]

I don't think that the user needs to be asked. If git is executing the hooks, I also expect GitButler to do so. I can't come up with a use case where you want regular git users to execute hooks but somehow GitButler users not.

[Timeraa]

I don't think that the user needs to be asked. If git is executing the hooks, I also expect GitButler to do so. I can't come up with a use case where you want regular git users to execute hooks but somehow GitButler users not.

Yeah, like why setup git hooks if you get the option to not run them by default? Like with normal git you can use --no-verify to disable them temporarily but they are on by default.

[jhnns]

Any decision on this? I understand that they are disabled as long as they're experimental, but I still think that they should be enabled by default.

[Byron]

Thanks for reinvigorating the discussion!

Maybe this is also something that could be presented as part of the onboarding in the future, so everything that is opt-out (like hooks in future maybe) can be presented once so the user knows. CC @PavelLaptev