Description of the problem, including code/CLI snippet

Quite often (for "user facing applications"), I find myself "needing to explain" why this failed.

For example:

commit = pc_project.commits.get(pc_ref)

which magically ✨, can return:

args = (<gitlab.v4.objects.commits.ProjectCommitManager object at 0x7ece058f5d60>, '10.8')
kwargs = {}

    @functools.wraps(f)
    def wrapped_f(*args: Any, **kwargs: Any) -> Any:
        try:
            return f(*args, **kwargs)
        except GitlabHttpError as e:
>           raise error(e.error_message, e.response_code, e.response_body) from e
E           gitlab.exceptions.GitlabGetError: 404: 404 Commit Not Found

.venv/lib/python3.12/site-packages/gitlab/exceptions.py:348: GitlabGetError

Now, you'd be right to claim PEBCAK. However, is it PEBCAK because the user somewhere wrote the input which eventually becomes input to this function as:

• 123456..., or, because he wrote
• 2025.09 expecting that this pc_ref is indeed any kind of ref, while the programmer expected it to be only a commit ref?

Same goes for:

• .branches.get(from_branch) (404 Branch not found)
• .project.files.get (404 File Not Found)

and maybe others - I will update as I find them.

I think the dissonance here happens because Gitlab's API expects "you did hand-held API operations" (/api/v4/projects/15/repository/commits/2025.09, ergo a 404 is much more obvious why), vs, when python-gitlab throws an exception, you don't even have access to the actual request attempted (path for GET requests, and additionally payload for the rest of the operations)

Expected Behavior

"Somehow" enhance stacktraces, so that the stacktrace is more actionable.

Actual Behavior

Specifications

• python-gitlab version: 6.4.0
• Gitlab server version (or gitlab.com):