Skip to content

Raise exception when git push fails #621

Description

@michaelkozakovsc

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

Activity

  1. NicoHood commented on May 13, 2017

    @NicoHood

    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.
    
  2. Byron commented on Jun 10, 2017

    @Byron
    Member

    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).

  3. David-Green commented on Aug 9, 2017

    @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.

  4. Byron commented on Sep 28, 2017

    @Byron
    Member

    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.

  5. michaelkozakovsc commented on Sep 28, 2017

    @michaelkozakovsc
    Author

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

    elif stderr_text:

  6. Wombleydude commented on Apr 18, 2018

    @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

  7. bagatonovic-remesh commented on Apr 25, 2018

    @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..."

  8. soumyadipdm commented on Apr 30, 2018

    @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'
    
  9. Byron commented on Jun 5, 2018

    @Byron
    Member

    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.

  10. JimNero009 commented on Mar 4, 2019

    @JimNero009

    Also been bitten by this recently...reviving!

  11. impredicative commented on Mar 4, 2019

    @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.

  12. 4 remaining items

  13. Byron commented on Jul 15, 2021

    @Byron
    Member

    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.

  14. added 3 commits that reference this issue on Oct 1, 2021
    e1110c1
    85a2ab5
    6a0a5c7
  15. added a commit that references this issue on Nov 8, 2021
  16. added a commit that references this issue on Nov 13, 2021
  17. CyrilBrulebois commented on Apr 9, 2022

    @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
  18. CyrilBrulebois commented on Apr 9, 2022

    @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?

  19. CyrilBrulebois commented on Apr 9, 2022

    @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.

  20. Byron commented on Apr 9, 2022

    @Byron
    Member

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

  21. added theissue type on Jul 20, 2026
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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions