On 2016-06-03 01:04 PM, Junio C Hamano wrote:
Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.
--
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