Skip to content

clone_from() returns no meaningful info of the errors in v3.1.11 #1087

Description

@zm0n3

When errors are involved in the cloning process, the clone_from() method doesn't preserve the original error message, instead it shows an exit code only.

Activity

  1. Byron commented on Nov 18, 2020

    @Byron
    Member

    I don't think this is true:

    >>> git.Repo.clone_from("https://github.com/foo/barbaz", "foo")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/byron/dev/GitPython/git/repo/base.py", line 1032, in clone_from
        return cls._clone(git, url, to_path, GitCmdObjectDB, progress, multi_options, **kwargs)
      File "/Users/byron/dev/GitPython/git/repo/base.py", line 973, in _clone
        finalize_process(proc, stderr=stderr)
      File "/Users/byron/dev/GitPython/git/util.py", line 329, in finalize_process
        proc.wait(**kwargs)
      File "/Users/byron/dev/GitPython/git/cmd.py", line 408, in wait
        raise GitCommandError(self.args, status, errstr)
    git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
      cmdline: git clone -v https://github.com/foo/barbaz foo
      stderr: 'Cloning into 'foo'...
    remote: Repository not found.
    fatal: repository 'https://github.com/foo/barbaz/' not found
    '
    >>>
    

    For information on how to use GitPython, there is plenty of documentation on how to do the basics.

  2. zm0n3 commented on Nov 18, 2020

    @zm0n3
    Author

    I don't think this is true:

    >>> git.Repo.clone_from("https://github.com/foo/barbaz", "foo")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/byron/dev/GitPython/git/repo/base.py", line 1032, in clone_from
        return cls._clone(git, url, to_path, GitCmdObjectDB, progress, multi_options, **kwargs)
      File "/Users/byron/dev/GitPython/git/repo/base.py", line 973, in _clone
        finalize_process(proc, stderr=stderr)
      File "/Users/byron/dev/GitPython/git/util.py", line 329, in finalize_process
        proc.wait(**kwargs)
      File "/Users/byron/dev/GitPython/git/cmd.py", line 408, in wait
        raise GitCommandError(self.args, status, errstr)
    git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
      cmdline: git clone -v https://github.com/foo/barbaz foo
      stderr: 'Cloning into 'foo'...
    remote: Repository not found.
    fatal: repository 'https://github.com/foo/barbaz/' not found
    '
    >>>
    

    For information on how to use GitPython, there is plenty of documentation on how to do the basics.

    Please add as argument the Progress() class defined here and try again. Stderr gets lost.

  3. Byron commented on Nov 19, 2020

    @Byron
    Member

    In that case one will have to parse stderr yourself, as it's now passed to the progress. My comment below applies to catch potential errors while progress is handled.

  4. zm0n3 commented on Nov 20, 2020

    @zm0n3
    Author

    In that case one will have to parse stderr yourself, as it's now passed to the progress. My comment below applies to catch potential errors while progress is handled.

    Unfortunately overriding the line_dropped() didn't help, I think there's much to modify in that util.py. By the way, it's weird that if we the ask the clone_from() to show realtime progresses, it just hides some things, especially ERRORS! I think this can be considered a bug, because in that condition it appears impossible to programmatically handle exceptions.

  5. Byron commented on Nov 21, 2020

    @Byron
    Member

    Without providing more information on how you tried to intercept line_dropped() calls, there is no way to tell why it didn't work for you.

    Errors are provided on stderr, and so are progress messages. I am sure there is a way to unify the handling so that errors and progress messages are always collected even if progress is collected on top.

    You are welcome to dig in and improve the situation in a PR.

  6. reopened this on Feb 26, 2021
  7. locked and limited conversation to collaborators on Feb 26, 2021
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

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions