The previous implementation tried to be an iterator over parents,
which ultimately was the wrong design choice and caused a lot of
headaches. Instead, this implementation is a simple branch iterator,
that will update it's position to the next parent, if one exists.
Not really sure why this wasn't my first approach, but I think I was
thinking about this in terms of parents, not actually commits. So I
didn't really see the forest for the trees.
This code implements a parsing strategy that uses lazy iterators to
traverse a branch graph. An iterator is constructed for a starting
point on a branch, and new iterators are spawned for every merge that
is encountered. To get all commits in a repository, simply do as
test.rs: queue new work to a channel, that you poll from until no more
branches have been discovered.
This code is somewhat suboptimal. For one, get_parent() is way too
complex, and could use some refactoring. Secondly, the semantics of
`BranchCommit::Branch(...)` are unclear from the outside, and the fact
that simple merge commits will be returned via `BranchCommit::Commit`,
while subsequent merge commits need to use `BranchCommit::Merge(...)`
is inconsistent and should be fixed before doing any sort of public
release!
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