Re: Commit graph not using minimal number of columns

[Junio C Hamano <gitster@pobox.com>]

Derrick Stolee <derrickstolee@github.com> 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.