Repository navigation
Raise exception when git push fails #621
Description
Activity
I have the same issue. An exception should be raised instead.
Error lines received while fetching: error: failed to push some refs to 'git@github.com:NicoHood/project.git' hint: Updates were rejected because the tag already exists in the remote.Reacted by Houtan Bastani, Romain François and Paul WittThis might be related to a change in the
gitprogram itself, as I believegit pushshould return with a none-zero exit status if it fails. Apparently this doesn't happen under certain circumstances (anymore).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.
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.
@Byron i think @David-Green was referring to this
Line 702 in 2b3c16c
elif stderr_text: 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 outputSorry 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..."
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'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.Reacted by DavidAlso been bitten by this recently...reviving!
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.
4 remaining items
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.- added 3 commits that reference this issue
on Oct 1, 2021 - added 2 commits that reference this issue
on Oct 12, 2021 - added a commit that references this issue
on Nov 8, 2021 - added a commit that references this issue
on Nov 13, 2021 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 thepush()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
For some reason, the
PushInfoListclass has been shipped since 35f7e94 aka.3.1.25~10but 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?Reacted by Timothy KlopotoskiIn 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
Exceptionworks well enough for me since I'm in a retry loop doing fetch & push inside atry/exceptblock):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.
Thanks for sharing! The flags should not change across releases as breaking changes are generally avoided.
- added a commit that references this issue
on Apr 27, 2022
Having to perform bit operations on
flagsis very unintuitive. The command line git client fails when push fails.