Closed
Description
If I do index.commit(msg)
it will execute pre-commit
and post-commit
That makes it very hard to do the equivalent of git commit -m "msg" --no-verify
(same as git commit -m "msg" -n
).
If I do index.commit(msg)
it will execute pre-commit
and post-commit
That makes it very hard to do the equivalent of git commit -m "msg" --no-verify
(same as git commit -m "msg" -n
).
Activity
peterbe commentedon Jun 13, 2016
We could just add another keyword parameter called
skip_hooks=False
which wraps those above mentioned calls in an if statement.Byron commentedon Jun 20, 2016
Thanks for bringing this to my attention ! I see the problem, and as a workaround for now, you could use git directly, such as in
repo.git.commit(m=msg, no_verify=true)
.Having something like the
skip_hooks
parameter seems like the way to go. I would be most grateful if you could submit a PR.nvie commentedon Jun 20, 2016
Sounds good. One suggestion though: should we stick with the same name for the parameter that git also uses? So
no_verify
, rather thanskip_hooks
? I always liked it that in many places GitPython doesn't require me to learn any new commands and flags and "normal" Git flags just work (given you just snake_case them of course).Byron commentedon Jun 20, 2016
Either way is fine with me. I understand those who say that 'no-verify' is a misleading (hooks can do more than just verify after all), and 'skip_hooks' would do exactly what it says it does.
One could add that GitPython supports the same arguments as the git process by just passing them through, and may thus use its own parameter names for its own implementation.
Personally I lean towards
skip_hooks
.nvie commentedon Jun 20, 2016
It was only a minor suggestion, I would not have minded either name I think. My discovery path with GitPython has often been that I know how to achieve something in Git, and then I would search the docs. In this case, I would possibly not find
no_verify
and perhaps falsely conclude it's not supported. Until I'd run into theskip_hooks
flags of course. But then I'd have to read the source code to make sure it's actually the same implementation and it's not actually doing more under the hood.It's a tough balance to strike as a library author: do you fix the thing you're wrapping, or do you mimic it (warts and all included)?
Perhaps a pragmatic approach here is to just use
skip_hooks
, but mention that this is really just doing a--no-verify
under the hood? That would solve both my issues: (1) searching for it is supported and (2) knowing that that is all it does.Byron commentedon Jun 20, 2016
Your suggestion seems like a solution to all problems you mentioned. I like it a lot !
Looks like the new flag is going to be called
skip_hooks
, whereas its parameter documentation mentions that it mimics--no-verify
or-n
.Commit without executing hooks, fixes gitpython-developers#468
3 remaining items