Fix 'PushInfo' object has no attribute 'name'

[thetwoj]

This PR addresses #820

As identified in the issue, running the following short script:

import git
git_client = git.Repo.clone_from(your_favorite_repo, 'test_clone')
result = git_client.remotes.origin.push()
print(result.summary)

Results in an exception like:

Traceback (most recent call last):
  File "/home/jj/scratch/GitPython/git/jjtestfile.py", line 4, in <module>
    print(result.summary)
  File "/home/jj/scratch/GitPython/git/util.py", line 877, in __getattr__
    if getattr(item, self._id_attr) == attr:
AttributeError: 'PushInfo' object has no attribute 'name'

This is a bit of a misleading exception because results is actually an IterableList(PushInfo, ...), not an instance of PushInfo. The implementation of IterableList is looking for the name attribute on the items it contains because that's the id_attr that is provided when the IterableList is created in _get_push_info():

output = IterableList('name')

Unfortunately this doesn't pan out well because PushInfo doesn't contain a name attribute, so the functionality that IterableList implements breaks down.

One way to resolve the issue would be to simply reference the PushInfo directly:

print(result[0].summary)

But the current exception prevents that from being obvious. After reading through the functionality exposed by IterableList I don't believe that it is actually providing any particular usefulness in this case because PushInfo doesn't contain any attributes that make for a logical id_attr. I think it makes more sense to replace this use of IterableList with a plain old list, that way the exception becomes much more helpful:

Traceback (most recent call last):
  File "/home/jj/scratch/GitPython/git/jjtestfile.py", line 4, in <module>
    print(result.summary)
AttributeError: 'list' object has no attribute 'summary'

[Byron]

Thanks a lot, @thetwoj , and thanks for the great explanation of the issue! You wouldn't believe how much it helps me to wrap my head around code I have written nearly 10 years ago 😅.

I absolutely agree with the reasoning and would prefer risking breakage through a (theoretical) interface change over not fixing the issue arising from it.