This is a component that I wanted to extract from `netmod-tcp`,
in the qaul.net tree. I was considering just moving this lib to the
utils tree in the qaul.net repo, but I decided that I needed this
library in too many other programs, and that it really didn't have
much to do with qaul.net so it's living here now.
Considering that I want to also convey stability in the API, I'll
immediately bump it to 1.0.0 as well.
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.
These are mostly not fleshed out, but I thought I'd write them
down. Maybe I'll develop them later.
Note to self: there was a third article I wanted to write, but I can't
remember what it was called 😅
