Commits may be missing in the commit list

[magik6k]

So this is something that is broken basically since the Scala version. Basically when we get the list of commits, we grab first few and display them. For the next page we pick a new 'base' commit for the list.

The problem is that there may be several 'base' commits at the same time (e.g. from merged branches), by picking a single base commit we loose some of the commits from the history.

[dirkmc]

@magik6k what do you think about the solution of always using an offset from the head commit? eg /repo/z8mW.../commits/20 to start from the 20th commit in the list (as long as the list is deterministically ordered)

This would mean that to render a direct link to that page we would need to start from the head and then fetch all the commits in between, but that's probably not a very common case

[magik6k]

That might work, but would be very painful when trying to view roots of really large repos (like Linux repo large).

We could also opt to render it with the branch lines (like github network view or git log --graph --oneline --decorate) and have continue/next button for each branch line, but this is probably still going to be problematic for linux-sized repos.

[magik6k]

Well, now that I think of it, it might make more sense to use the 'branch lines' for large repos as it makes the history into a tree, which makes more sense for git repos (getting back to Linux example - it's almost impossible to find anything in linear Linux repo history, being able to view it as a tree would make it easier to follow multi-layer merges)

[dirkmc]

Hmm yeah that's true, ordering history by committer date is not super intuitive to a person looking at the commit list, it would be more intuitive to look at branch lines. On the other hand ordering by committer date is probably the most performant for this kind of use case, in that you can immediately start rendering the commits in the correct order while you're still fetching them.

Next I was going to look at creating a prioritized prefetch queue that goes and fetches the things that you are most likely to click on next when you land on a page. So from the repo root it would prefetch the commit list for the current branch and the dirs and files in the tree that you're looking at. This might help with performance for rendering the branch lines.

[magik6k]

There is a third option which should work - first page is at /repo/z8mW.../commits and looks as it does currently, but:

• When we get the list of commits we keep track of heads
• After we fetch all commits to display, we fetch 1 more for each head
• We construct some kind of IPLD node with a set of [date -> commitCid] links
• We then use CID of this node for /repo/z8mW.../commits/headsCid
• The rest is (displaying) history

One downside is that we can end up storing those objects for a long time, but this shouldn't be a major problem because this is what gc is for. We should also be able to encode objects with ~2-10 links using identity hash so we wouldn't have this problem in repos with few concurrent branches.

This gets us links that work for displaying sorted combined history at some point in time without having to traverse from the head of ref.