From: Marc Branchaud Date: Fri, 03 Jun 2016 14:53:27 GMT Subject: Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines Message-ID: <575199E7.7000503@xiplink.com> In-Reply-To: <20160603110843.15434-4-pclouds@gmail.com> On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote: > When there are lots of ref updates, each has different name length, this > will make it easier to look because the variable part is at the end. s/look/read/ For the record, I prefer the earlier stair-step format to this {xxx -> yyy}/foo stuff. Peff suggested that a two-pass approach might not be too bad, but had problems when he tried it with extra-long refs. Maybe those problems could be dealt with, and we could get a simple, aligned output? 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 > --- > Documentation/git-fetch.txt | 7 +++++++ > builtin/fetch.c | 37 ++++++++++++++++++++++++++++++++++++- > t/t5510-fetch.sh | 4 ++-- > t/t5526-fetch-submodules.sh | 26 +++++++++++++------------- > 4 files changed, 58 insertions(+), 16 deletions(-) > > diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt > index 18e733c..61c3bd1 100644 > --- a/Documentation/git-fetch.txt > +++ b/Documentation/git-fetch.txt > @@ -113,6 +113,13 @@ representing the status of a single ref. Each line is of the form: > -> () > ------------------------------- > > +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 . I'm not sure how to describe it succinctly, especially since it's not always used. Really there are two possible output formats: { -> } () -> () This is starting to feel too complex. M.