Assign commits to versions following their commit graph (fixes #70)

[chme]

This is my attempt at fixing #70.

The solution in this PR is different from #70, but in my opinion, it makes the code easier to read and understand.
The first solution had some issues with certain commit graphs (especially, when there are more than one previous version).

I made the following assumptions:

• A commit should only be listed in exactly one version. And this version is the oldest version.
• The previous version is the one that is found when following the left branch of the commit graph (ignoring merges).

I'll need to test this a bit more (especially if the last assumption is OK), but wanted to open this PR to get an early feedback.

I removed the Version.next_version field. If it is better to keep it, I can reintroduce it.

One of the tests has an ugly sleep(1) in it. Unfortunately Git only has second precision and without the sleep, the comit order of git log is undetermined for commits that happen in the same second (and are not related).

And one final not, this PR is based on #71.

[pawamoy]

Just a few suggestions. I'm going to review the rest in my editor as I think I'll probably modify the code a bit. I'll add a review here once I'm confident about my changes 🙂

[pawamoy]

I went ahead and applied the suggestions, I hope you don't mind 🙂
I've also pushed a fixup commit with the changes I was talking about. Basically, where you had a TODO about perfs, I changed the code to use a map of commits. This map is passed to each Commit object, so they can hydrate their parent commits from their hashes only, in a property. A commit's parent commits will therefore always be up-to-date when we modify its parent hashes directly.

Other changes are to maintain backward compatibility. The parse_commits method keeps returning the list of all commits, and we build the list of tag commits in the above layer by iterating on them.

[pawamoy]

Some more cosmetic changes.

[pawamoy]

OK, sorry for the spam haha, just two more comments for which I'd like to hear your opinion 😄
Thank you so much for this contribution, this is really, really great!

[chme]

I added a commit, that changes how the previous version is found.

As you can see in the test case "test_two_release_branches" it is a bit odd / unexpected, that the previous version of "unreleased" was 1.1.0 (instead of 2.0.0). And even stranger, that version 2.0.0 did not have a previous version.

Thinking about it, in my opinion, it is best to use the highest semantic version, that is found in the commit graph.
If you want more test cases, let me know if there are specific scenarios you are interested in being covered by a test.

[pawamoy]

As you can see in the test case "test_two_release_branches" it is a bit odd / unexpected, that the previous version of "unreleased" was 1.1.0 (instead of 2.0.0). And even stranger, that version 2.0.0 did not have a previous version.
Thinking about it, in my opinion, it is best to use the highest semantic version, that is found in the commit graph.

That is a good remark. I think I agree with you: all versions that are not already present in the changelog should be ordered semantically (semver) rather than chronologically (tag date). It's particularly important for the "compare with previous version" URL, since we probably only want to compare a version with its semantically previous one, not the chronologically previous one.

[pawamoy]

Minor changes.

[pawamoy]

(If you can, try to avoid force-pushing, as it makes reviewing a bit more difficult 😉)

[chme]

I think, I addressed all review comments. Let me know, if there is something else to do for this MR.

[pawamoy]

LGTM, thanks!