This is done by stepping through a branch iterator to diff commits to
see where they changed. This is somewhat computationally intensive,
and also doesn't work well yet because iterator stepping is done
internally and there is no API to extend iterators before they are
run. That means that histories can only be read from first-parent
iterators.
Ideally we would do two things here:
1. build an API to let iterators extend themselves, either breadth
first, or depth first. But maybe that would be too much
complexity for the iterator module?
2. figure out a better way to get the history of a file. At the
moment we are stepping through commits and diffing them with
parents to find the set of changed paths. I don't _think_ there is
a way to simply compare refs, but maybe there is.
This implementation is a bit weird, especially because it changes the
API from what it was previously. This works, for now, but some of the
relationships between types feel a bit bad. Especially that all
queries have to go via the FileTree, and we can't just give out
objects that represent some part of the tree that are then loaded when
needed.
For now this will work though. What's still missing is to turn a
Yield::Dir into a new FileTree.
This code is work-in-progress, and doesn't work on a repo that has a
branched history. The issue here is that after handling a merge
commit, keeping track of which commit to look at next is non-trivial.
This solution tries to isuse a "skip" command on the walker, but this
can accidentally skip commits, when two merges have happened in
succession (maybe a bug with the impl, not the concept).
But also, the actual merge commit seems to already be part of the
norma history? So maybe we can ommit the merge commit explicitly, and
simply return a new branch handle instead.
Katharina Fey