Add support for git_graph_descendant_of

[chadrik]

Fixes issue #815

Let me know if this should be added to the docs, and if so, which section.

[chadrik]

Also, do you think it's worth adding a feature like this:

branches = repo.branches.with_commit(oid)
for branch in branches:
    print(branch)
print('master' in branches)

I would achieve this with a new __init__ argument to the Branches class that would constrain the results of __getitem__ and __iter__ to branches that contained the passed commit id.

[jdavid]

Yes please add to the docs, just in docs/repository.rst

[jdavid]

Yes that sounds good, but would not be better branches.contains(...)? to mimic git branch --contains

[chadrik]

I added the docs. Let me know if you had something more in mind.

Yes that sounds good, but would not be better branches.contains(...)? to mimic git branch --contains

That was my original thought, but I felt that branches.contains() feels like a method that should return a boolean (do the branches contain something, yes or no?), whereas branches.with_commit() seems to better indicate that it will return more branches. Also, it makes it more clear that it has something to do with commits. Ultimately, it's your call, though. Let me know what you think.

[jdavid]

I would rather call self._valid(branch_name) to avoid a lookup in the case that self._commit is None, which is probably the most common case.

[chadrik]

Good point, but I don't want to incur the lookup in the case of __getitem__ where we already have a branch reference object. Check my latest commit for what I think is a good compromise.

[jdavid]

Sounds good, true with_commit is more intuitive.

Could you add a test for with_commit? See the review as well.

Thanks!

[chadrik]

Could you add a test for with_commit? See the review as well.

Yep, just wanted to get sign off on the general design first.

[chadrik]

Updated! Let me know what you think.

[jdavid]

Merged, thanks!