Skip to content

Commit without executing hooks #468

Closed
@peterbe

Description

@peterbe
Contributor

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

peterbe commented on Jun 13, 2016

@peterbe
ContributorAuthor

We could just add another keyword parameter called skip_hooks=False which wraps those above mentioned calls in an if statement.

added this to the v2.0.6 - Bugfixes milestone on Jun 20, 2016
Byron

Byron commented on Jun 20, 2016

@Byron
Member

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

nvie commented on Jun 20, 2016

@nvie
Contributor

Sounds good. One suggestion though: should we stick with the same name for the parameter that git also uses? So no_verify, rather than skip_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

Byron commented on Jun 20, 2016

@Byron
Member

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

nvie commented on Jun 20, 2016

@nvie
Contributor

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 the skip_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

Byron commented on Jun 20, 2016

@Byron
Member

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.

added a commit that references this issue on Jun 20, 2016
e031a0e

3 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      Participants

      @peterbe@Byron@nvie

      Issue actions

        Commit without executing hooks · Issue #468 · gitpython-developers/GitPython