Order of git commits often wrong

[nomeata]

In our instance, I often observe that codepeed gets confused when several revisions with the same commit date (e.g. due to a rebase before pushing a branch) are added. It seems it only takes the date into account when calculating what comes before what, and that obviously fails here.

It may not fit the current code structure well, but it really should order commits based on their parent-child-relationship.

[nomeata]

This is getting more annoying, and a showstopper for serious use of codespeed in a git-based project. Basically, for git, the date has no significance and should not be used.

I guess you want an extra column “ordering” for the Revisions object which can be filled with a VCS-dependent value. It may be a date (e.g. seconds since the epoch), or a revision number. For git, as an approximation, it may be the the number of parent commits, if that is easily obtainable for GitHub.

[nomeata]

(I tried to make myself work on this feature, and it might be feasible for the pure “changes”, but the “trends” feature makes this a big more complicated.)

[tobami]

I understand the problem. I guess the original csv date ordering assumption works well for git as long as you don't do things like rebase.

What did you try out so far? Ordering by author date instead of committer date would work in your case, but getting it programmatically is not trivial.

[nomeata]

I didn’t try anything, just stared at the code and considered various options.

Author date is also not good. People might use git rebase -i to reoder commits. Really, the order of commits has to come from the child-parent metadata...

[nomeata]

People here at ICFP say that using the author date would be an improvement. It seems to be trivial at least for the github backend (change 'committer' to 'author') (which is what I use).