Re: [PATCH] graph.c: visual difference on subsequent series

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 03.09.2015 19:13:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>>> Is the design of your independent implementation the same except
>>> that 'o' is used instead of 'x'?  Independent implementation does
>>> not make the same design magically better, if that is the case ;-)
>>
>> Interestingly, the patch to the tests lists * to o changes only, no < or
>>> to o.
> 
> Well, in that case, then the opposite but an equivalent problem
> exists in the design, no?  It promises to make roots stand out by
> painting them as 'o', but it sometimes fails to do so.  In other
> words, ...
> 
>> The reason is simply that the patch doesn't change anything for left nor
>> right commits. I would say that is the best compromise since it does not
>> change the overall layout, provides more information by default and does
>> not override information that is requested specifically.
> 
> ... it fails your last criteria.

How would it? "--left-right" information is requested specifically and
not overridden. Root information is not requested specifically [by the
user].

>> If we want to put more information into log --graph simultaneously we
>> should really go beyond ASCII and look at how tig does it, e.g. using
>> unicode characters.
> 
> That's another way to do so, but shifting columns to show where the
> history is not connected also does not change the overall layout,
> provides more information by default, etc., and a big plus is that
> it would be an approach to do so without having to go beyond ASCII.

That would consume more horizontal space and annoy at least some people.
Alternatively, we could use more vertical space and annoy at least some
(other?) people.

In fact, I tend to think that horizontal space is more "precious" than
vertical space due to the common orientation of scrolling...

If we don't mind an increase in vertical spacing there are more issues
that could be solved, for example the merge point description sticking
visually to the commits above rather than the merged branch in the
typical old..new scenario.

In fact, both issues would be solved be adding an extra line after a
root commit (be it "real" root or boundary-wise).

Michael