Assertion fails when fetching with prune=True

[eswierk]

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]

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]

Hey..

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

[mwoehlke-kitware]

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]

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]

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]

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.