Re: [jgit-dev] Optimizing EGit's HistoryView

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, May 2, 2012 at 7:45 AM, Lay, Stefan <stefan.lay@xxxxxxx> wrote:
> 2. Additionally switch off RevSort.TOPO
>
> The main effect would result from 1 + 2. What would be the consequence of not doing RevSort.TOPO?

If TOPO is disabled, an incorrectly dated descendant commit can show
up after its parent in the output. This would position the descendant
in the history viewer below its parent, which would make the line have
to draw in the reverse direction, which it will probably not do
correctly and may cause illegal argument exceptions or other nasty
breakages from the painting library. :-)

What happens here is clock skew. When a committer makes a commit on a
system whose clock is behind the clock of someone else he is working
with, and there is more than one branch active in the project history
at this point in time, the priority queue will pop the commits in the
"wrong" order for graph display and you get the incorrectly dated
commit at the wrong point in the plot.

> Would it otherwise be possible to do the sorting incrementally, i.e. sorting only the commits which are loaded?

It is possible, but JGit doesn't support this yet. git-core supports
it with a --incremental flag to rev-list that is used by gitk. Most
Git commit graphs for most sections don't have a difference between
TOPO and non-TOPO sorting. So incremental pretends there is no problem
and outputs commits early. When a descendant is printed after its
parent, incremental signals an ordering change, and I think reprints
everything, after TOPO sorting the section of the graph it has already
output. The viewer sees this ordering change signal and replots its
entire UI with the new ordering.

You would need to do something similar with RevWalk, or do it higher
up in some sort of wrapper.

> Or can everything be sorted but without keeping all the traversed commits in memory?

Not really. :-(