On 02/21/2012 09:10 PM, Junio C Hamano wrote:
Zbigniew Jędrzejewski-Szmek<zbyszek@xxxxxxxxx> writes:
This seem overly complex. A nice property to have would be
"if the window is wide enough so there's enough space for full
filenames, the graph part scales monotonically with the change count".
(If there's filename truncation, than there just isn't enough space
for everything and the graph may be compressed. But otherwise, if we
have two graphs which do not end at the edge of the screen, and the
second one is wider than the first one, then without looking at the
change counts we know that the second one has more changes).
For this property to be satisfied, the graph_width limit would have to
be independent of the filename width.
So maybe it should be ...
Sorry, the desired property I would understand, but that does not click
with your "have to be independent" conclusion, so I do not have comment on
the "maybe it should be..." part.
Hi,
by "scales monotonically with the change count" I meant with two
different commits. Image that there are two commits
a | 300 ++++++++++++++++++++++
and
a/a/a/b | 300 ++++++++++++++++++++++
Both commits have the same change count, but filenames of different
length. If the filename length can influence the number of "+" in the
graph, then the scaling is not monotonic. There would always be cases
when a bigger change with longer filenames has a narrower graph.
The resolution requirement may want to set a "desired lower limit" for the
width of the graph, but it is only "desired" because it is possible that
you have to bust the limit if you have three files with 1, 9999 and 10000
changed lines and your terminal is only 200 columns wide.
The current code caps name part to 50/80, but allows the graph to use more
when you have only shorter names. Perhaps you can follow the same logic
in the first part of your [7/8] (which needs to be separated to at least
in two pieces, as it conflates the "lift 50-column cap from the name width
and make it proportional to the term_width()" part and "but cap the graph
part to 40-column" part, that are separate topics)? Then we can try
different heuristics to find a better way to cap the length of the graph
on top?
Sure. I'll be replying to this mail with patches
[7.1/8] use a maximum of 5/8 for the filename part
[7.2/8] add a test for output with COLUMNS=40
[7.3/8] limit graph part to 40 columns
--
Zbyszek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html