Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

[Marc Branchaud <marcnarc@xiplink.com>]

On 2016-06-03 01:04 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> What if we detect when the full line exceeds the terminal width, and
>> insert a newline after the remote ref and indent the ->  to the same
>> offset as its surrounding lines, like this:
>>
>>   * [new branch]      2nd-index -> pclouds/2nd-index
>>   * [new branch]      some-kind-of-long-ref-name
>>                                 -> pclouds/some-kind-of-long-ref-name
>>   * [new branch]      3nd-index -> pclouds/3nd-index
>
> I am OK with this format (not in the sense that I like it better
> than what the patch produces, but in the sense that I do not have
> strong preference either way).  It may be hard to come up with a
> good heuristics to decide where on the display width "->" should
> come, though.

I think aligning it with the -> on the other lines makes the most 
aesthetic sense.

Are you worried that the right-hand-side ref might still wrap?  I'm not 
too concerned about that -- there'll always be the possibility of a ref 
name that's longer than the terminal.

>>> +When `from` and `to` share a common suffix, the line could be
>>> +displayed in the form:
>>> +
>>> +-------------------------------
>>> + <flag> <summary> {<from> -> <to>}<suffix> (<reason>)
>>
>> If we go with this format, we'll need to document <suffix>.
>
> The sentence above calls it "a common suffix", so instead of saying
> <suffix> we can say <common-suffix> perhaps?  Or did you mean
> something more than that?

I missed that, and although I think it's an adequate description I think 
most readers will miss it too.  They eye tends to notice the 
syntax-description bits then skip down to the list of element 
descriptions to understand which bits mean what.  My brain wants to find 
"suffix" in that list.

Anyway, not a major issue, really.

		M.