Re: Commit graph not using minimal number of columns

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 26, 2023, 16:10 UTC
Message-ID: <xmqq1qk6vd3v.fsf@gitster.g>
In-Reply-To: <86188f31-f492-d195-d4d5-b0582906621a@github.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.

Show 6 quoted lines

> 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.