Skip to content

Assertion fails when fetching with prune=True #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
eswierk opened this issue Sep 28, 2011 · 6 comments
Closed

Assertion fails when fetching with prune=True #32

eswierk opened this issue Sep 28, 2011 · 6 comments
Assignees

Comments

@eswierk
Copy link

eswierk commented Sep 28, 2011

I'm occasionally hitting an assertion failure when calling remote.fetch(prune=True). It appears to fail only when some remote-tracking branch is actually pruned. For example:

File "/usr/local/lib/python2.7/dist-packages/GitPython-0.3.2.RC1-py2.7.egg/git/remote.py", line 593, in fetch
return self._get_fetch_info_from_stderr(proc, progress or RemoteProgress())
File "/usr/local/lib/python2.7/dist-packages/GitPython-0.3.2.RC1-py2.7.egg/git/remote.py", line 539, in _get_fetch_info_from_stderr
assert len(fetch_info_lines) == len(fetch_head_info), "len(%s) != len(%s)" % (fetch_head_info, fetch_info_lines)
AssertionError: len("fcf7e70bc1df0fad8b08d088df46c6d778b4579f\tnot-for-merge\tbranch 'master' of github.com:foo/bar\n"]) != len([' 4a2be28..fcf7e70 master -> foo/master', ' x deleted -> foo/release'])

Apparently when the remote-tracking branch release was pruned, it was removed from .git/FETCH_HEAD but was still mentioned in the fetch info lines. Maybe lines starting with ' x [deleted]' should simply be removed from the fetch info lines?

@Byron
Copy link
Member

Byron commented Jun 7, 2012

Thanks for bringing this up !
The fetch code is probably a bit picky, and relies solely on parsing output of git-fetch and git-push. There are many places where it can go aw, and its a bit difficult to test properly.

However, it should be fixed in any way!

@Jomaj4
Copy link

Jomaj4 commented Feb 25, 2013

Hey..

Is there any solution yet? I've got the same problem.

@mwoehlke-kitware
Copy link

Here also on an initial fetch...

fetch_head_info looks like a bunch of porcelain-stuff, with fetch_info_lines almost matching, except that the latter also has an additional "POST git-upload-pack (316 bytes)" that doesn't match any fetched branch

@hashar
Copy link
Contributor

hashar commented Jul 25, 2014

If one could find a way to reproduce the git setup and the related python code to trigger the assertion error. That will help fix the issue :-]

@mwoehlke-kitware
Copy link

As far as the git setup, I would guess:

  1. Create two local repositories, with the first (call it "upstream") a remote of the second (call it "test").
  2. Create a branch in upstream.
  3. Update test (can do with git CLI; the point here is just so that test knows about origin/<branch>).
  4. Remove the branch in upstream.
  5. Run a GitPython remote.fetch(prune=True).

(This exact setup isn't necessary, just that the test repository "knows" about a remote branch that no longer exists in the remote.)

@Byron Byron added this to the v0.3.5 - bugfixes milestone Nov 14, 2014
@Byron Byron self-assigned this Jan 8, 2015
@Byron
Copy link
Member

Byron commented Jan 8, 2015

I was unable to reproduce the issue in the latest version. This makes sense as the assertion in question was changed to be less picky. Also the way the matching of FETCH_HEAD information with progress information works was improved ever so slightly.
In effect, the issue seems resolved.

@Byron Byron closed this as completed Jan 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants