From: Marc Branchaud Date: Fri, 03 Jun 2016 20:00:01 GMT Subject: Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines Message-ID: <5751E1C1.8080507@xiplink.com> In-Reply-To: On 2016-06-03 01:04 PM, Junio C Hamano wrote: > Marc Branchaud 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: >>> + >>> +------------------------------- >>> + { -> } () >> >> If we go with this format, we'll need to document . > > The sentence above calls it "a common suffix", so instead of saying > we can say 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.