GitPython is a python library used to interact with Git repositories.

Overview

Gitoxide: A peek into the future…

I started working on GitPython in 2009, back in the days when Python was 'my thing' and I had great plans with it. Of course, back in the days, I didn't really know what I was doing and this shows in many places. Somewhat similar to Python this happens to be 'good enough', but at the same time is deeply flawed and broken beyond repair.

By now, GitPython is widely used and I am sure there is a good reason for that, it's something to be proud of and happy about. The community is maintaining the software and is keeping it relevant for which I am absolutely grateful. For the time to come I am happy to continue maintaining GitPython, remaining hopeful that one day it won't be needed anymore.

More than 15 years after my first meeting with 'git' I am still in excited about it, and am happy to finally have the tools and probably the skills to scratch that itch of mine: implement git in a way that makes tool creation a piece of cake for most.

If you like the idea and want to learn more, please head over to gitoxide, an implementation of 'git' in Rust.

GitPython

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

It provides abstractions of git objects for easy access of repository data, and additionally allows you to access the git repository more directly using either a pure python implementation, or the faster, but more resource intensive git command implementation.

The object database implementation is optimized for handling large quantities of objects and large datasets, which is achieved by using low-level structures and data streaming.

REQUIREMENTS

GitPython needs the git executable to be installed on the system and available in your PATH for most operations. If it is not in your PATH, you can help GitPython find it by setting the GIT_PYTHON_GIT_EXECUTABLE=<path/to/git> environment variable.

  • Git (1.7.x or newer)
  • Python >= 3.4

The list of dependencies are listed in ./requirements.txt and ./test-requirements.txt. The installer takes care of installing them for you.

INSTALL

If you have downloaded the source code:

python setup.py install

or if you want to obtain a copy from the Pypi repository:

pip install GitPython

Both commands will install the required package dependencies.

A distribution package can be obtained for manual installation at:

http://pypi.python.org/pypi/GitPython

If you like to clone from source, you can do it like so:

git clone https://github.com/gitpython-developers/GitPython
git submodule update --init --recursive
./init-tests-after-clone.sh

Limitations

Leakage of System Resources

GitPython is not suited for long-running processes (like daemons) as it tends to leak system resources. It was written in a time where destructors (as implemented in the __del__ method) still ran deterministically.

In case you still want to use it in such a context, you will want to search the codebase for __del__ implementations and call these yourself when you see fit.

Another way assure proper cleanup of resources is to factor out GitPython into a separate process which can be dropped periodically.

Windows support

See Issue #525.

RUNNING TESTS

Important: Right after cloning this repository, please be sure to have executed the ./init-tests-after-clone.sh script in the repository root. Otherwise you will encounter test failures.

On Windows, make sure you have git-daemon in your PATH. For MINGW-git, the git-daemon.exe exists in Git\mingw64\libexec\git-core\; CYGWIN has no daemon, but should get along fine with MINGW's.

The easiest way to run tests is by using tox a wrapper around virtualenv. It will take care of setting up environments with the proper dependencies installed and execute test commands. To install it simply:

pip install tox

Then run:

tox

For more fine-grained control, you can use unittest.

Contributions

Please have a look at the contributions file.

INFRASTRUCTURE

  • User Documentation
  • Questions and Answers
  • Please post on stackoverflow and use the gitpython tag
  • Issue Tracker
    • Post reproducible bugs and feature requests as a new issue. Please be sure to provide the following information if posting bugs:
      • GitPython version (e.g. import git; git.__version__)
      • Python version (e.g. python --version)
      • The encountered stack-trace, if applicable
      • Enough information to allow reproducing the issue

How to make a new release

  • Update/verify the version in the VERSION file
  • Update/verify that the doc/source/changes.rst changelog file was updated
  • Commit everything
  • Run git tag -s <version> to tag the version in Git
  • Run make release
  • Close the milestone mentioned in the changelog and create a new one. Do not reuse milestones by renaming them.
  • set the upcoming version in the VERSION file, usually be incrementing the patch level, and possibly by appending -dev. Probably you want to git push once more.

How to verify a release

Please only use releases from pypi as you can verify the respective source tarballs.

This script shows how to verify the tarball was indeed created by the authors of this project:

curl https://files.pythonhosted.org/packages/09/bc/ae32e07e89cc25b9e5c793d19a1e5454d30a8e37d95040991160f942519e/GitPython-3.1.8-py3-none-any.whl > gitpython.whl
curl https://files.pythonhosted.org/packages/09/bc/ae32e07e89cc25b9e5c793d19a1e5454d30a8e37d95040991160f942519e/GitPython-3.1.8-py3-none-any.whl.asc >  gitpython-signature.asc
gpg --verify gitpython-signature.asc gitpython.whl

which outputs

gpg: Signature made Fr  4 Sep 10:04:50 2020 CST
gpg:                using RSA key 27C50E7F590947D7273A741E85194C08421980C9
gpg: Good signature from "Sebastian Thiel (YubiKey USB-C) <[email protected]>" [ultimate]
gpg:                 aka "Sebastian Thiel (In Rust I trust) <[email protected]>" [ultimate]

You can verify that the keyid indeed matches the release-signature key provided in this repository by looking at the keys details:

gpg --list-packets ./release-verification-key.asc

You can verify that the commit adding it was also signed by it using:

git show --show-signature  ./release-verification-key.asc

If you would like to trust it permanently, you can import and sign it:

gpg --import ./release-verification-key.asc
gpg --edit-key 4C08421980C9

> sign
> save

Projects using GitPython

LICENSE

New BSD License. See the LICENSE file.

DEVELOPMENT STATUS

Python package Documentation Status Packaging status

This project is in maintenance mode, which means that

  • …there will be no feature development, unless these are contributed
  • …there will be no bug fixes, unless they are relevant to the safety of users, or contributed
  • …issues will be responded to with waiting times of up to a month

The project is open to contributions of all kinds, as well as new maintainers.

Comments
  • Type Hints

    Type Hints

    Hello,

    I was looking for any type hints for GitPython, but I found nothing neither in the code nor in independent stub repositories.

    Is there any plan to introduce type hinting?

    enhancement help wanted 
    opened by mdantonio 56
  • Git, GitDB, and GitCmdObjectDB give different results when counting objects.

    Git, GitDB, and GitCmdObjectDB give different results when counting objects.

    1. Use git to count the objects in a repo:
    $ git rev-list --objects --all | wc -l
    6990030
    $ git rev-list --objects --all | sort | uniq | wc -l
    6990030
    
    1. Parse the output from git rev-list --objects --all, fetch each object with name_to_object, and count each type:
    Commits: 909667, Tags: 2469, Trees: 4178263, Blobs: 1899631
    
    1. Query what is ostensibly the same information using git-python:
    import argparse
    import pathlib
    
    import git
    
    def log(testname, a, b):
        print(testname, ':', a, b)
    
    def main():
    
        parser = argparse.ArgumentParser(description='Git x ref.')
        parser.add_argument('repository', metavar='repository', type=pathlib.Path,
                            help='Path to Git repository.')
    
        args = parser.parse_args()
    
        repos = [
            git.Repo(str(args.repository), odbt=git.GitCmdObjectDB),
            git.Repo(str(args.repository), odbt=git.GitDB)
        ]
    
        log('size()', *[r.odb.size() for r in repos])
        log('len(sha_iter())', *[sum(1 for x in r.odb.sha_iter()) for r in repos])
        log('len(iter_trees())', *[sum(1 for x in r.iter_trees()) for r in repos])
    
    
    if __name__ == '__main__':
        main()
    

    Result:

    size() : 3839 8268978
    len(sha_iter()) : 3839 8268978
    len(iter_trees()) : 568851 568851
    

    So:

    Git thinks there are 6,990,030 objects in the database. GitDB thinks there are 8,268,978. GitCmdObjectDB thinks there are 3,839.

    Git thinks there are 4,178,263 trees in the database. Both GitDB and GitCmdObjectDB think there are 568,851.

    wont fix 
    opened by ali1234 54
  • Progress not showing up before the last second

    Progress not showing up before the last second

    I've implemented the Progress class to implement a nice progress bar:

    • https://github.com/guyzmo/git-repo/blob/master/git_repo/services/service.py#L46-56

    I'm then using it, for example here:

    • https://github.com/guyzmo/git-repo/blob/master/git_repo/services/service.py#L196-202

    And then, when I clone a very large repository (like mozilla's gecko):

    % git hub clone mozilla/gecko-dev
    Pulling from github |████████████████████████████████|
    Successfully cloned `https://github.com/guyzmo/git-repo` into `./git-repo`!
    

    the progress bar is "progressing" (i.e. incrementing from 0 to 100%), but it shows up only at the very end of the fetching, after hanging for a long while. I started to debug it, and it looks like it's related to subprocess stuff.

    Though, I might be implementing it wrong, which is why I'm asking here while I'm still debugging that issue.

    acknowledged 
    opened by guyzmo 35
  • CVE-2022-24439: `<gitpython::clone> 'ext::sh -c touch% /tmp/pwned'` for remote code execution

    CVE-2022-24439: ` 'ext::sh -c touch% /tmp/pwned'` for remote code execution

    This appeared in the CVE feed today: https://security.snyk.io/vuln/SNYK-PYTHON-GITPYTHON-3113858

    Not sure if this was reported to you before or not, reporting it here just in case.

    acknowledged critical help wanted 
    opened by mmuehlenhoff 29
  • Some files are never closed

    Some files are never closed

    I'm working on a script using GitPython to loop over lots of Git repos, pull remote changes, etc...

    At some point, I noticed that doing repo.is_dirty() was opening some files which never got closed until the process exits, which in turns causes the tool to crash with "too many open files" after iterating over enough repos:

    import os
    
    import git
    
    # Put here whatever Git repos you might have in the current folder
    # Listing more than one makes the problem more visible
    repos = ["ipset", "libhtp"]
    
    raw_input("Check open files with `lsof -p %s | grep %s`" % (os.getpid(),
                                                                os.getcwd()))
    
    for name in repos:
        repo = git.Repo(name)
        repo.is_dirty()
    
        del repo
    
    raw_input("Check open files again")                 # files are still open
    

    I tried digging deeper down the GitPython stack, but couldn't find the actual cause.

    In case that's helpful, below is the same as the previous snippet, but using directly the lowest-level gitdb objects I could find to open the files:

    import os
    
    import git
    from gitdb.util import hex_to_bin
    
    # Put here whatever Git repos you might have in the current folder
    # Listing more than one makes the problem more visible
    repos = ["ipset", "libhtp"]
    
    raw_input("Check open files with `lsof -p %s | grep %s`" % (os.getpid(),
                                                                os.getcwd()))
    
    raw_input("Check open files again")                 # files are still open
    
    for name in repos:
        repo = git.Repo(name)
        sha = hex_to_bin("71acab3ca115b9ec200e440188181f6878e26f08")
    
        for db in repo.odb._dbs:
            try:
                for item in db._entities:               # db._entities opens *.pack files
                    item[2](sha)                        # opens *.idx files
    
            except AttributeError as e:
                # Not all DBs have this attribute
                pass
    
        del repo
    
    raw_input("Check open files again")                 # files are still open
    

    But that's just where the files are open (well, in fact they are open even lower down but I didn't manage to go deeper), not where they are supposed to be closed.

    acknowledged critical tag.leaks 
    opened by bochecha 28
  • Test project on Windows with MINGW git (conda2.7&3.4/cpy-3.5)

    Test project on Windows with MINGW git (conda2.7&3.4/cpy-3.5)

    • Use Appveyor integration servers;
    • Copy part of the travis logic, to speed-up test-time (no flake8, site & coverage), the only extra is wheel-packaging;
    • Limit combination of Anaconda, CPython and MINGW/Cygwin in only 6 variations.
    • Replaced poll/select buffer-assembly code with pump-threads (Win TCs faling 90-->20!) and rework unicode handling in many places.
    • Popen() procs it with subprocess.CREATE_NEW_PROCESS_GROUP so that they can be killed.
    • Invoke MINGW git-daemon (instead of git daemon); otherwise it detaches (unix-ism here) from parent git cmd, and then CANNOT DIE!
    • Stop reading directly Popen().proc.stdout/stderr from the launching-thread, it freezes due to GIL/buffering.
      • Unslurp diff consumption code (but not raw-patch) to handle it line-by line to support arbitrary big output.
    • Ensure read-only files do delete on Windows. +Rework GitCommandError.str() and add TCs on unicode handling.
    • Fixed TCs on config-reader/writer:
      • Modify lock/read-config-file code to ensure files closed.
      • Use with GitConfigarser() more systematically in TCs.
      • Clean up any locks left hanging from prev TCs.
      • Util: mark lock-files as SHORT_LIVED; save some SSDs...
    • Fixed TestRepo.test_submodule_update():
      • submod: del .git file prior overwrite; Windows denied otherwise!
    • FIX TestRepo.test_untracked_files():
      • In the git add <file> case, PY2 fails when args are unicode. Must encode them with locale.getpreferredencoding() AND use SHELL.
    • cmd: add shell into execute() kwds, for overriding USE_SHELL per command.
    • repo: replace blocky communicate() in _clone() with thread-pumps (UNNECESSARY, see this later discussion).
    • test_repo.py: unittestize (almost all) assertions.
    • Fixed file-access problems by using with... construct (not complete).
      • Replace open --> with open for index (base and TC).
    • Enabled some TCs, more remain dormant (ie the Hook TC never runs on Linux).
      • test_index.py: Enabled dormant fake-symlink assertion.
    • Various encoding issues.
    • Debug-log all Popen() calls, to collect cmd usage.

    Apveyor results

    • Py27: FAILED (SKIP=3, errors=1)
    • Py34: FAILED (SKIP=3, errors=3)
    • Py35 : FAILED (SKIP=3, errors=3)
    acknowledged tag.leaks 
    opened by ankostis 24
  • Surface fetch/pull/push kill_after_timeout and reset default to None

    Surface fetch/pull/push kill_after_timeout and reset default to None

    (hopefully) closes #1339 This PR does as of e058c4c :

    • renames timeout to kill_after_timeout and set default to None instead of 10 s
    • Surfaces kill_after_timeout to user facing functions (remote. pull/push/fetch)
    • refactor AutoInterrupt so we can ._terminate() the underlying process and grab status codes from terminated processes
    • Add a class variable AutoInterrupt._status_code_if_terminate; if non-zero it overrides any status code from the process in _terminate. This can be used to prevent race conditions in tests, as described in this comment

    Some history of the commits (while trying a different strategy):

    aafb300 changes the default timeout to 60 s 1d26515 allows push, pull and fetch keyword timeout that will be propagated down febd4fe alters some tests to use the old 10 s timeout for fetch and pull 4113d01 also alters a test call to pull to add a timeout of 10s c55a8e3 fixes the test suite 7df33f3e sets the default timeout to None

    if the current default is too lose, users can now give their own timeout

    opened by sroet 21
  • Issues with AutoInterrupt in conjunction with sys.exit on python 3.5

    Issues with AutoInterrupt in conjunction with sys.exit on python 3.5

    The destructor of the cmd class (actually AutoInterrupt) seems to throw some errors using python 3.5 on Arclinux:

    Exception ignored in: <bound method Git.AutoInterrupt.__del__ of <git.cmd.Git.AutoInterrupt object at 0x7f7c2b101d68>>
    Traceback (most recent call last):
      File "/usr/lib/python3.5/site-packages/git/cmd.py", line 294, in __del__
    TypeError: 'NoneType' object is not callable
    Exception ignored in: <bound method Git.AutoInterrupt.__del__ of <git.cmd.Git.AutoInterrupt object at 0x7f7c2b101cc0>>
    Traceback (most recent call last):
      File "/usr/lib/python3.5/site-packages/git/cmd.py", line 294, in __del__
    TypeError: 'NoneType' object is not callable
    

    It seems this error is triggered by a call to sys.exit(0) at the end of my script, since it doesn't appear if I comment it out. However I couldn't reproduce this behavior with python 2.7, here sys.exit(0) seems to be working with the module correctly.

    What I do is simply clone a repo, add some files commit and push them to a remote.

    ...
    repo = Repo.clone_from(target_git_path, target_temp_dir)
    ...
    repo.index.add([file])
    ...
    repo.index.commit('Initial commit')
    ...
    refspec='refs/heads/{0}:refs/heads/{0}'.format(repo.active_branch) # this will fix error if user has set "push.default = matching"
    repo.remotes.origin.push(refspec=refspec)
    
    waiting for feedback acknowledged 
    opened by Heiko-san 21
  • ModuleNotFoundError: No module named 'gitdb.utils.compat'

    ModuleNotFoundError: No module named 'gitdb.utils.compat'

    Requirments file includes gitdb2 and, but "compat.py" file is importing "gitdb" instead and throwing missing "gitdb" module error when this library is fresh installed in a new enviroment with missing "gitdb" dependency library. Please fix the problem.

    acknowledged 
    opened by mell0 20
  • Assert fails in GitPython 0.3.5 comparing FETCH_HEAD and branches actually fetched

    Assert fails in GitPython 0.3.5 comparing FETCH_HEAD and branches actually fetched

    Stack trace:

    Traceback (most recent call last):
      File "/usr/local/lib/python2.7/site-packages/fabric/main.py", line 743, in main
        *args, **kwargs
      File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 424, in execute
        results['<local-only>'] = task.run(*args, **new_kwargs)
      File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 174, in run
        return self.wrapped(*args, **kwargs)
      File "/var/lib/abc/ramble/venom/fabfile.py", line 286, in deploy_celery
        prepare_deploy(settings, branch_name=branch_name)
      File "/var/lib/abc/ramble/venom/fabfile.py", line 195, in prepare_deploy
        repo_install_path=install_path)
      File "/var/lib/abc/ramble/ramble/utils/git_util.py", line 31, in set_deploy_context
        remote.fetch()
      File "/usr/local/lib/python2.7/site-packages/git/remote.py", line 613, in fetch
        res = self._get_fetch_info_from_stderr(proc, progress or RemoteProgress())
      File "/usr/local/lib/python2.7/site-packages/git/remote.py", line 552, in _get_fetch_info_from_stderr
        fetch_info_lines)
    AssertionError: len(....) <= len (...) (elided for length)
    

    I wrote a script to parse the two things that it is trying to compare, from the assert output. FETCH_HEAD right now has 813 lines. The output of git fetch, when I run it manually on the command line (I have not been able to figure out exactly what command it is running, but I'm assuming it's git fetch --all -v - is this correct?) has also 813 lines if you ignore the first two lines: Fetching origin and From github.com:org/repo

    However, the very last 4 branches in FETCH_HEAD are missing in the GitPython fetch output, the last of which is this line:

    a3a81646dd65dfa4b4412c0f3a5fd4183cbaa2e5 not-for-merge branch 'zendesk' of github.com:org/repo

    It can't find the matching line in the fetch output (or for the previous 3):

    = [up to date] zendesk -> origin/zendesk

    Even though I see the above lines when I do git fetch --all -v, I don't see the last 4 lines in the GitPython assert output. Let me know if you need more info. Is there possibly some length limit? I'm using git 1.8.3.4.

    BTW I was using GitPython==0.3.2.RC1 prior to this and it was still failing an assertion, although I'm not sure the assertion was exactly the same.

    acknowledged 
    opened by domino14 18
  • GPG signatures for source validation

    GPG signatures for source validation

    As we all know, today more than ever before, it is crucial to be able to trust our computing environments. One of the main difficulties that package maintainers of Linux distributions face, is the difficulty to verify the authenticity and the integrity of the source code.

    The Arch Linux team would appreciate it if you would provide us GPG signatures in order to verify easily and quickly your source code releases.

    Overview of the required tasks:

    • Create and/or use a 4096-bit RSA keypair for the file signing.
    • Keep your key secret, use a strong unique passphrase for the key.
    • Upload the public key to a key server and publish the full fingerprint.
    • Sign every new git commit and tag.
    • Create signed compressed (xz --best) release archives
    • Upload a strong message digest (sha512) of the archive
    • Configure https for your download server

    GPGit is meant to bring GPG to the masses. It is not only a shell script that automates the process of creating new signed git releases with GPG but also comes with this step-by-step readme guide for learning how to use GPG.

    Additional Information:

    • https://github.com/NicoHood/gpgit
    • https://help.github.com/categories/gpg/
    • https://wiki.archlinux.org/index.php/GnuPG
    • https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
    • https://www.qubes-os.org/doc/verifying-signatures/
    • https://lkml.org/lkml/2016/8/15/445
    • https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
    • https://www.enigmail.net/index.php/en/

    Thanks in advance.

    PS: I plan to use this module in gpgit soon. However this and #611 is a blocking issue for this to happen. Would be really nice to see gpg signatures as well as this project part of gpgit.

    acknowledged 
    opened by NicoHood 17
  • remove forced verbose output for pull on a remote

    remove forced verbose output for pull on a remote

    Noticed that there is no verbose option when performing pull on a remote, and it is hardcoded to be verbose. Adding a keyword argument, similar to this change

    opened by gal-leib 1
  • Make separate sub-tree-view vs just-git-tree classes or git.Tree runtime modes

    Make separate sub-tree-view vs just-git-tree classes or git.Tree runtime modes

    This enhancement proposal is motivated by confusion in the behavior of subtrees. Issue #851 is one example. This stackoverflow question is another example.

    As further example consider the following bash+python script behavior:

    mkdir testrepo
    cd testrepo
    git init
    mkdir 1
    mkdir 2
    echo hi > 1/hi.txt
    cp 1/hi.txt 2/.
    git add .
    git commit -m 'test'
    

    and then

    import git
    
    repo = git.Repo()
    one = repo.head.commit.tree['1']
    two = repo.head.commit.tree['2']
    print("Same object?", one is two)
    print("Same Python hash?", hash(one) == hash(two))
    print("Same git hash?", one.hexsha == two.hexsha)
    print("Equal?", one == two)
    print("Same paths?", one.path == two.path)
    print("hi.txt in one and two?", "hi.txt" in one, "hi.txt" in two)
    print("1/hi.txt in one and two?", "1/hi.txt" in one, "1/hi.txt" in two)
    print("2/hi.txt in one and two?", "2/hi.txt" in one, "2/hi.txt" in two)
    

    which prints out:

    Same object? False
    Same Python hash? False
    Same git hash? True
    Equal? True
    Same paths? False
    hi.txt in one and two? False False
    1/hi.txt in one and two? True False
    2/hi.txt in one and two? False True
    

    What I think most people would expect is that "hi.txt" is contained in both one and two and 1/hi.txt and 2/hi.txt are contained in neither one nor two. This is essentially the same issue noted in #851.

    I think most people would also not expect these Tree objects to be ==-equal but then also have a property path that has different values.

    It seems to me the fundamental problem is that the Tree class is trying to behave like two things that are different things:

    • a git tree, in the git object database
    • a subdirectory/subtree in a git index

    In the sample above, one and two are the same git tree but they are not the same subdirectory added to a git index. A git tree does not have a path but a subdirectory added to a git index does. The current __contain__ logic is kind-of-OK if the objects are subdirectories added to a git index, but make no sense for a git tree.

    Due to backwards compatibility, this seems a challenging issue to address. I don't know the code and backwards compatibility situation well enough to make any recommendations. But I'm happy to help. I can suggest some different approaches, but I figure it's best to seek your @Byron input on this first.

    opened by castedo 11
  • pulling from private repo

    pulling from private repo

    I can clone from a private repo by specifying the path to he ssh key, like this:

    git_dir = "[email protected]:user_id/repo_name.git"
    save_at = './'
    Repo.clone_from(git_dir, save_at, env={"GIT_SSH_COMMAND": 'ssh -o StrictHostKeyChecking=no  -i ./my_path/mykey'})
    

    However, I this code cannot pull from the same private repo

    repo = Repo(save_at)
    ssh_cmd =  'ssh -o StrictHostKeyChecking=no  -i ./my_path/mykey'}
    with repo.git.custom_environment(GIT_SSH_COMMAND=ssh_cmd):
        repo.remotes.origin.pull('master')
    

    and throws the error

    File "/usr/local/lib/python3.10/site-packages/git/remote.py", line 910, in pull
        res = self._get_fetch_info_from_stderr(proc, progress,
      File "/usr/local/lib/python3.10/site-packages/git/remote.py", line 750, in _get_fetch_info_from_stderr
        proc.wait(stderr=stderr_text)
      File "/usr/local/lib/python3.10/site-packages/git/cmd.py", line 502, in wait
        raise GitCommandError(remove_password_if_present(self.args), status, errstr)
    git.exc.GitCommandError: Cmd('git') failed due to: exit code(1)
      cmdline: git pull -v origin master
      stderr: 'fatal: Could not read from remote repository.'
    

    What am I missing here?

    waiting for feedback Q&A 
    opened by rogelioamancisidor 2
  • `invalid literal for int() with base 10: 'x'` when diffing commits

    `invalid literal for int() with base 10: 'x'` when diffing commits

    Traceback (most recent call last):
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/cmd.py", line 114, in pump_stream
        handler(line)
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/diff.py", line 570, in <lambda>
        handle_process_output(proc, lambda byt: cls._handle_diff_line(byt, repo, index),
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/diff.py", line 557, in _handle_diff_line
    python-BaseException
        diff = Diff(repo, a_path, b_path, a_blob_id, b_blob_id, old_mode, new_mode,
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/diff.py", line 303, in __init__
        self.a_mode = mode_str_to_int(a_mode) if a_mode else None
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/objects/util.py", line 80, in mode_str_to_int
        mode += int(char) << iteration * 3
    ValueError: invalid literal for int() with base 10: 'x'
    The above exception was the direct cause of the following exception:
    Traceback (most recent call last):
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/threading.py", line 946, in run
        self._target(*self._args, **self._kwargs)
      File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/git/cmd.py", line 120, in pump_stream
        raise CommandError([f'<{name}-pump>'] + remove_password_if_present(cmdline), ex) from ex
    git.exc.CommandError: Cmd('<stdout-pump>') failed due to: ValueError('invalid literal for int() with base 10: 'x'')
      cmdline: <stdout-pump> git diff-tree 81a1f0c4f84aeb6ee97edea64251419515eff571 8c38dfe86157463d745c453d9a1d8c066cc9b7c5 -r --abbrev=40 --full-index -M --raw -z --no-color
    

    This is my first time posting an issue, so please tell me what extra information is needed!

    waiting for feedback 
    opened by bobeatslollipop 2
  • --object-format=sha256 support

    --object-format=sha256 support

    When I git init --object-format=sha256 I receive

    Traceback (most recent call last):
      ...
      File "/usr/local/lib/python3.9/site-packages/git/repo/fun.py", line 163, in name_to_object
        raise BadName(name)
    gitdb.exc.BadName: Ref 'HEAD' did not resolve to an object
    

    because the hash size is longer

    acknowledged help wanted 
    opened by cblp 1
  • mypy error due to missing typing of **kwargs in Remote.fetch()

    mypy error due to missing typing of **kwargs in Remote.fetch()

    Just happen to notice that in GitPython == 3.1.27 the static typing pip mypy fails to recognize the **kwargs of Remote.fetch() in remote.py. This happens because the kwargs argument is typed as Any, which is plausible but may be narrowed down to e.g. Union[None, Dict[str, int, bool]]. For the correct list of possible types we'd need to check docs at git-fetch.

    Use case is the following code snippet:

        def fetch_all(self, repository: git.Repo) -> List[git.FetchInfo]:
            fetch_kwargs = {'tags': True, 'force': True, 'prune': True, 'prune-tags': True}
    
            origin_server = repository.remotes.origin
            origin_server.fetch(**fetch_kwargs)  # Note: mypy does not recognize kwargs because GitPython does type it as Any
            fetch_info_list = origin_server.pull()
    
            return fetch_info_list
    

    (Code above is my custom code and not part of this project!)

    Edit: Using mypy==0.971 and mypy-extensions==0.4.3. Not sure if mypy should ignore this at least we can help it find a potential type.

    acknowledged help wanted c-typing 
    opened by maunzCache 1
Releases(3.1.30)
Python library to interact with a Z-Wave JS server.

zwave-js-server-python Python library for communicating with zwave-js-server. Goal for this library is to replicate the structure and the events of Z-

Home Assistant Libraries 54 Dec 18, 2022
A python library to interact with the EarnApp API

EarnApp.py Table of contents General info Documentation Setup General info A python library to interact with the EarnApp API. Documentation First, imp

null 3 Dec 14, 2022
A github actions + python code to extract URLs to code repositories to put into standard form, starting with github

A github actions + python code to extract URLs to code repositories to put into standard form, starting with github ---- NOTE: JUS

Justin Gosses 2 Nov 15, 2021
A Python script that wraps the gitleaks tool to enable scanning of multiple repositories in parallel

mpgitleaks A Python script that wraps the gitleaks tool to enable scanning of multiple repositories in parallel. The motivation behind writing this sc

Emilio Reyes 7 Dec 29, 2022
A python script fetches all your starred repositories from your GitHub account and clones them to your server so you will never lose important resources

A python script fetches all your starred repositories from your GitHub account and clones them to your server so you will never lose important resources

Ringo Hoffmann 27 Oct 1, 2022
Revolt.py - An async library to interact with the https://revolt.chat api.

Revolt.py An async library to interact with the https://revolt.chat api. This library will be focused on making bots and i will not implement anything

Zomatree 0 Oct 8, 2022
A library that revolutionizes the way people interact with NextDNS.

NextDNS-API An awesome way to interface with your NextDNS account - via Python! Explore the docs » Report Bug . Request Feature Table Of Contents Abou

null 34 Dec 7, 2022
Python API to interact with Uwazi

Python Uwazi API Quick Start To use the API install the requirements pip3 install -r requirements.txt and use it like this: uwazi_adapter = UwaziAdap

HURIDOCS 2 Dec 16, 2021
Autodrive is designed to make it as easy as possible to interact with the Google Drive and Sheets APIs via Python

Autodrive Autodrive is designed to make it as easy as possible to interact with the Google Drive and Sheets APIs via Python. It is especially designed

Chris Larabee 1 Oct 2, 2021
An async python wrapper to interact with the Steam API and its CMs

steam.py A modern, easy to use, and async ready package to interact with the Steam API. Heavily inspired by discord.py and borrowing functionality fro

James Hilton-Balfe 90 Dec 15, 2022
Algofi Python SDK is useful for developers who want to programatically interact with the Algofi lending protocol

algofi-py-sdk Algofi Python SDK Documentation https://algofi-py-sdk.readthedocs.

Algofi 41 Dec 15, 2022
Stop writing scripts to interact with your APIs. Call them as CLIs instead.

Zum Stop writing scripts to interact with your APIs. Call them as CLIs instead. Zum (German word roughly meaning "to the" or "to" depending on the con

Daniel Leal 84 Nov 17, 2022
A small bot to interact with the reddit API. Get top viewers and update the sidebar widget.

LiveStream_Reddit_Bot Get top twitch and facebook stream viewers for a game and update the sidebar widget and old reddit sidebar to show your communit

Tristan Wise 1 Nov 21, 2021
Interact and easily use Google Chat room webhooks.

Chat Webhooks Easily interact and send messages with Google Chat's webhooks feature. This API is small, but should be a nice framework for working wit

BD103 2 Dec 13, 2021
A telegram bot to interact with a Minecraft Server

telegram-mc-bot A telegram bot to interact with a Minecraft Server It has the following commands: /status - Returns the server status (Online/Offline)

KleynArt 1 Dec 9, 2021
This is a small package to interact with the OpenLigaDB API.

OpenLigaDB This is a small package to interact with the OpenLigaDB API. Installation Run the following to install: pip install openligadb Usage from o

null 1 Dec 31, 2021
A Git Alert Bot - Github Integration for Pyrogram & Telethon

Yet Another GitAlertBot Inspired From @Pokurt's GitGram Run Bot: Local Host Git Clone Repo : For Telethon Version : git clone https://github.com/DevsE

DevsExpo 23 Oct 21, 2022
Adds a new git subcommand named "ranch".

Git Ranch This script adds ranch, a new subcommand for git that makes it easier to order 1 Gallon of Kraft Ranch Salad Dressing from Amazon. Installat

Austin T Schaffer 8 Jul 6, 2022
Sends messages to a Discord webhook whenever you make a new commit to your local git repository.

Git-Notif Sends messages to a Discord webhook whenever you make a new commit to your local git repository. Usage Just drop notifier.py into your git h

null 1 May 29, 2022