Commit access to tree and parents oids

[jdavid]

We need something like Commit.tree_oid, that we can use instead of Commit.tree.oid, which would fail if the tree object is missing in the database. The same about Commit.parents.

[carlosmn]

Is there a reasonable use-case for having a commit with a tree that's missing in the repo's database? Are you thinking of doing something like fsck?

[jdavid]

fsck is a perfectly legit use case.

More fundamentally, I see things the other way. The property of the commit is the tree-oid, not the tree. The ability to get the tree directly from the commit is just sugar, a short way to write repo[commit.tree_oid].

Related to this, I would like every call that returns a git-object to go through a central function. For instance, Commit.tree should call lookup_object, and not build up the tree object on its own. This way, one day, we may implement a cache at the Python level, for instance.

[bpollack]

The other use-case: sometimes, we don't actually need to materialize the whole tree; we may have it in cache. But we won't know that unless we can check the tree ID first. As-is, this results in hitting the disk needlessly. The patch for this is simple, and I'm happy to contribute it.

[jdavid]

Please go ahead. The question is whether Commit.tree_oid and Commit.parent_oids should return raw or hex oids, in my opinion it should be raw oids.

PS: Another question is whether to keep or not the sugar. But that could be decided later.