Repository navigation
Can't catch GitCommandError #1924
Description
I am trying to do a cherry-pick, but abort when it fails:
import git
...
git = repo.git
try:
git.cherry_pick(commit)
except git.GitCommandError as e:
git.cherry_pick(abort=True)
...but I get this:
except git.GitCommandError as e:
TypeError: catching classes that do not inherit from BaseException is not allowed
Now I can obviously do except Exception as e... But, I would like to be explicit to defer code-paths.
Activity
Byron commentedon Jun 1, 2024
Thanks for reporting!
This seems fixable and testable, and even though I don't know what's the best way to fix this, somebody coming along will.
Thanks for helping.
EliahKagan commentedon Jun 1, 2024
The problem is not with the
GitCommandErrorexception, which works fine inexceptclauses and, like all exceptions in Python code, does derive ultimately fromBaseException.This is instead a bug in the code you showed. That code does not catch that exception, because that exception is not what really appears in the
exceptclause. The problem is this assignment statement:Before that,
gitwas thegitmodule, whoseGitCommandErrorattribute is an exception. After that,gitis an instance of theGitclass. All subsequent uses ofgitare as ifrepo.githad been used. So then you have:Because you reassigned
git, this is like:In most cases, a bug like this would result in an
AttributeError. But the attributes of aGitinstance, unless otherwise present, are dynamically generated functions that, when called, invoke thegitexecutable to rungitcommands. For example,repo.git.gcis a function that, when called, runs agit gccommand. Likewise,repo.git.GitCommandErroris a function that, when called, runs agit GitCommandErrorcommand.(Of course, the
gitexecutable has noGitCommandErrorsubcommand. So calling it would fail, unless aGitCommandErroralias has been defined, agit-GitCommandErrorscript or other executable can be found in$PATH, or a future or alternative version ofgitis in use that has such a subcommand. Being open-ended in this way allowsGitinstances to be usable for all those things. That thegitexecutable recognizes noGitCommandErrorsubcommand is not relevant to what you are observing, though, since you you are attempting to catchrepo.git.GitCommandError, not to call it. The key is that attempting to catch this function as though it were an exception type definitely fails: not only is it not an exception type, it is not even a type.)One way to fix the bug in the code you showed would be to use a different variable name in the assignment, so that
gitstill refers to the module that it referred to due to theimportstatement.zerothi commentedon Jun 3, 2024
Ha, so true!!! How did I miss that :) Thanks!
zerothi commentedon Jun 3, 2024
Might I propose that https://gitpython.readthedocs.io/en/latest/tutorial.html#using-git-directly changes
git = repo.gitto something else? That was my inspiration ;)Byron commentedon Jun 4, 2024
Thanks so much for sharing, I wasn't aware!
Do you think you could give that change a try? It's in
test/test_doc.py, and it's CI-tested so nothing can go wrong.I would love it if that could be contributed.
fixed doc to not faulty do gitpython-developers#1924
zerothi commentedon Jun 13, 2024
done!
Merge pull request #1932 from zerothi/1924-docs