Rugged::Tree and Rugged::Index do similar things but have different APIs

[ioquatix]

(Relates to #683)

It would be nice if Rugged::Index and Rugged::Tree provided the same methods where possible. For example, it would be nice if both supported the same interface for reading and enumerating objects.

Some ideas:

• Both should support fetch(path, default=nil, &block) for looking up a path entry.
• Both should support each(prefix=nil) for enumerating entries efficiently.
• Other methods where it makes sense (e.g. each_tree, each_blob).

Some of these might also extent to Rugged::Tree::Builder, but I'm not sure how feasible that is.

[ioquatix]

This relates to #672 for efficient enumeration of trees and indexes too.

[ioquatix]

Another important difference is how Rugged::Index#each and Rugged::Tree#each handle nested paths.

Since the index is flat, it would naturally enumerate all sub-paths, but for the tree, that's a little bit different.

Not sure yet what the correct behaviour here should be.

[ioquatix]

This is now low priority as I wrote my own change handling and no longer use Rugged::Index, but prefer Rugged::Tree#update and my own change tracking/cache. However, I still think it is a good idea to consider this feedback.

[carlosmn]

Those similarities come from both of them being, at their bases, lists of items, such that it probably makes sense for them to implement enumeration. But that's not because they're similar to each other, but to a list of items.

What they contain and represent are pretty different, especially with the index containing metainformation like tree caches and resolve-undo information as well as multiple entries for the same path.