Re: pre-commit hook not run on conflict resolution during rebase
Junio C Hamano gits...@pobox.com wrote: li...@haller-berlin.de (Stefan Haller) writes: I guess the next best solution would be to also have a pre-push hook that performs the same checks again, just in case the bad code managed to get past the pre-commit hook for some reason or other. This feels very redundant, but I guess it would work well. I'd say pre-receive would be the most sensible place to check things like this. Yes, I totally agree, and we used to have this setup when we were still hosting our code in-house; with pre-receive doing the authorative checks, and pre-commit being optional as a convenience for developers, as you say. Now we have moved most of our code to github, and you can't have pre-receive hooks there, as far as I can tell. (I should have mentioned that, sorry.) To make up for that, we have put considerable effort into ensuring that everyone on the team has up-to-date hooks locally, by installing them automatically as part of our build system infrastructure. In that light, do you agree that a pre-push hook is the best we can do now to plug this hole? -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pre-commit hook not run on conflict resolution during rebase
li...@haller-berlin.de (Stefan Haller) writes: When a rebase stops because of a conflict, and I edit the file to resolve the conflict and say git rebase --continue, then the pre-commit hook doesn't run at that point,... From glancing through the githooks manpage, I couldn't see any other hook that would help in this situation. Am I missing something? I do not think so. There may be some fallouts, like negatively affecting folks who have been relying on the current behaviour, but I do not see a fundamental reason why that hook should not trigger there (it may not trigger in the current implementation, but I view it as lack of need so far, not a deliberate omission). I guess the next best solution would be to also have a pre-push hook that performs the same checks again, just in case the bad code managed to get past the pre-commit hook for some reason or other. This feels very redundant, but I guess it would work well. I'd say pre-receive would be the most sensible place to check things like this. Some of your developers may not have pre-commit hook or even run commit --no-verify to bypass the local check, and if you have a central meeting place for the efforts by all your folks, that is where you want to enforce the policy. Checks done anywhere else are what are redundant, including the pre-commit hook in individual developers. You can view them as a way for individual developers to save their time---by choosing to check locally, they make sure their commits do not trigger the pre-receive hook at the central place. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pre-commit hook not run on conflict resolution during rebase
When a rebase stops because of a conflict, and I edit the file to resolve the conflict and say git rebase --continue, then the pre-commit hook doesn't run at that point, which means that I can commit bad stuff which the pre-commit hook would normally not allow in. We were bitten by this a few times already. (In our case, the hook rejects code that hasn't been run through clang-format. That's easy to forget when resolving conflicts during a rebase.) From glancing through the githooks manpage, I couldn't see any other hook that would help in this situation. Am I missing something? I guess the next best solution would be to also have a pre-push hook that performs the same checks again, just in case the bad code managed to get past the pre-commit hook for some reason or other. This feels very redundant, but I guess it would work well. Any other suggestions? -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
