[GSoC PATCH WIP RFC v3 0/3] graph: add --graph-lane-limit option

[Pablo Sabater <pabloosabaterr@gmail.com>]

When viewing the history of a repository that has many branches, the graph output
can become very wide easily, making it difficult to read and sometimes pushing the 
commit messages to the right and breaking the format. 

Introduce --graph-lane-limit option to truncate the graph at n + 1/2 lanes (n lanes
plus the column between the lane and the truncation mark). Lanes over the limit
are replaced with '.' keeping the graph readable and shows all the information
about the visible lanes.

commit mark '*' is shown in two cases:

- When the commit lives on a visible lane.
- When the commit lives on the first hidden lane (n+1) this case instead of
  '.' it will show '*' to show that there is a commit in the first hidden lane.

Any commit on deeper branches won't show any mark, but the commit subject will 
still be shown.

Coming from graph_output_commit_line, merge-lanes with no relevant information
on the visible lanes (neither commit or parent lives on a visible lane) are
skipped making the graph more compact.

The original idea to limit columns was noted as a TODO in
c12172d2ea (Add history graph API, 2008-05-04), which mentions
gitk's behavior. This does not implement gitk-style column
rearrangement; it only truncates the visual output.

RFC and WIP:

1. On lane-limited graphs, there are collapsing, merge and padding lanes that don't
   add any information to the graph.

     - graph_output_collapsing_line mixes state handling and graph rendering, skipping
       this function entirely, as is done with post-merge, would corrupt the mapping
       so the function needs to be run but returning an empty buffer is not expected
       by the callers and produces blank lanes.

     - Suppressing redundant lanes like merges or collapses that come from graph_next_line().
       graph_show_remainder() and graph_show_commit_msg() emits newlines hoping that
       all lines will have content to print, returning an empty buffer to them
       results in blank lines because of newlines being duplicated. graph_show_remainder
       would be called from two places with different newlines needs, to make
       this work graph_show_remainder() needs to be refactored. Doing this will result
       in shorter graphs with less redundant lines on lane-limited graphs. Given that
       the graph.c code is 17 years old is this desired ?

2. To keep the most information rendered on lane-limited graphs, collapsing and
   merges are rendered as usual but when the collapse or merge to hidden lanes, 
   the information about from where and to where it goes it lost, are they still
   useful ? if not, it could be desirable to remove them like in point 1.

Pablo Sabater (3):
  graph: add --graph-lane-limit option
  graph: truncate graph visual output
  graph: add documentation and testing about --graph-lane-limit

 Documentation/rev-list-options.adoc |   5 ++
 graph.c                             | 130 ++++++++++++++++++++++++----
 graph.h                             |   2 +
 revision.c                          |  11 +++
 revision.h                          |   1 +
 t/t4215-log-skewed-merges.sh        |  53 ++++++++++++
 6 files changed, 185 insertions(+), 17 deletions(-)


base-commit: dc6ecd5354dca88d51b6d6562777fc8fc10d77e1
-- 
2.43.0