Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
> This width is necessary to avoid crossing lines _given the order
> of the commits_, which is picked independently of the graph
> rendering.
Thanks for giving the crucial bit.
Object listing order is determined first, and then graph algorithm
works on the series of commits that comes out of the revision
walking machinery.
> I don't think there is anything actionable to do here, as
> these commit-ordering options are well-defined and should not
> be altered. If there was an algorithm to modify the commit
> order in such a way that minimized the graph output, that
> would be interesting, but the cases it minimizes are probably
> too rare to be worth the effort.
Yes, in addition to and next to "--{topo,date}-order", if somebody
can come up with a new "--graph-friendly-order", it may be an
interesting addition.
A tangent. I do not offhand remember if --date-order works purely
on the timestamps in the commit objects, or do we take corrections
based on the generation numbers? It seems that we only use the
compare_commits_by_gen_then_commit_date helper for prio queue
manipulation (to avoid the "slop" thing terminating the revision
walk too early) and not actual sorting. I wonder if it makes much
difference if we used it instead of compare_commits_by_commit_date()
Thanks.
