Raise exception when git push fails

[michaelkozakovsc]

Having to perform bit operations on flags is very unintuitive. The command line git client fails when push fails.

[NicoHood]

I have the same issue. An exception should be raised instead.

Error lines received while fetching: error: failed to push some refs to '[email protected]:NicoHood/project.git'
hint: Updates were rejected because the tag already exists in the remote.

[Byron]

This might be related to a change in the git program itself, as I believe git push should return with a none-zero exit status if it fails. Apparently this doesn't happen under certain circumstances (anymore).

[David-Green]

Is problem that it's eating the exception here

https://github.com/gitpython-developers/GitPython/blob/master/git/remote.py#L702

Should always raise an exception, warning text also references fetch instead of push.

[Byron]

Is this still an issue? The links provided don't refer to a specific commit, thus the lines shift and make it hard to find the point you refer to, in retrospective. Thank you.

[michaelkozakovsc]

@Byron i think @David-Green was referring to this

GitPython/git/remote.py

Line 702 in 2b3c16c

elif stderr_text:

[Wombleydude]

This has also been an issue for me using 2.1.5:
When doing :
self.repo = Repo('repo_dir')
self.repo.remotes[0].push(self.repo.head.reference.name)
Get this logging:
(remote.py:702) WARNING > Error lines received while fetching: error: failed to push some refs to 'ssh://xxxxxxx' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.

But in fact I want this to be an exception. It does look like the following lines that are the problem (at line 730 in the current master:
except Exception:
if not output:
raise
elif stderr_text:
log.warning("Error lines received while fetching: %s", stderr_text)
return output

[bagatonovic-remesh]

Sorry to pile on, but this just bit my team today too. We were moving a few hundred repos, and a few of them failed to push with mirror to the new remote, yet the script exited successfully with no errors but never actually pushed the repo. Trying to push with command line gives us "error: failed to push some refs to..."

[soumyadipdm]

I got bitten by this too while trying to automate git push.

2018-04-30 11:12:37,693 WARNING git.remote Error lines received while fetching: error: failed to push some refs to 'git@xxxxxx:yyyyyy/zzzzz.git'

[Byron]

Do you think fixing this would be possible for one of the people having been bitten by this?
The code to alter should be right here.
Probably changing the behaviour from logging to throwing an exception would be desirable, even though it technically is a breaking change.

[JimNero009]

Also been bitten by this recently...reviving!

[impredicative]

I have had to use some very serious checking to detect and handle failed pushes with gitpython==2.1.11 and it's bonkers that I had to try so hard.

[artgoldberg]

Agree. Errors should be reported as exceptions.

[KalenWessel]

Also was just bit by this issue.

[rfrancois]

Also was just bit by this issue.

[Byron]

As a general question: What about submitting a PR with a new push_or_throw(…) method, which does as it says? There should be enough references in this thread to implement it without spending too much time on research.

[CyrilBrulebois]

In case someone else stumbles on this very strange behaviour, and doesn't immediately dive into Sjord's commits (mentioned in this issue, above this comment): raise_if_error() can now be called on the object returned by the push() call.

That landed in 3.1.25, and the tutorial has an example:

# push and pull behaves similarly to `git push|pull`
origin.pull()
origin.push()  # attempt push, ignore errors
origin.push().raise_if_error()  # push and raise error if it fails

[CyrilBrulebois]

For some reason, the PushInfoList class has been shipped since 35f7e94 aka. 3.1.25~10 but can't be found by searching for it on https://gitpython.readthedocs.io/en/latest/ (latest or specific versions). So I suppose some extra doc metadata is needed to improve discoverability?

[CyrilBrulebois]

In case someone needs to work with a slightly older version (e.g. 3.1.14, available in Debian 11), here's something that seems to do the trick for me (keeping in mind raising a generic Exception works well enough for me since I'm in a retry loop doing fetch & push inside a try/except block):

origin.pull(rebase=True)
# Workaround for missing origin.push().raise_if_error() in 3.1.14
# (see https://github.com/gitpython-developers/GitPython/issues/621):
pushinfolist = origin.push()
for pi in pushinfolist:  # pylint: disable=invalid-name
    for flag in [pi.REJECTED, pi.REMOTE_REJECTED, pi.REMOTE_FAILURE, pi.ERROR]:
        if pi.flags & flag:
            raise Exception("error flag %d set" % flag)

Caveat: I had to hardcode which flags look like errors I should care about; not sure how stable it is going to be across releases.

[Byron]

Thanks for sharing! The flags should not change across releases as breaking changes are generally avoided.