Re: Ideas for even more compact fetch.output=compact output

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2019, 18:19 UTC
Message-ID: <xmqqftsfr8hw.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACsJy8DJvxuhVJBpgTNiFHt+0ZOFqm4agvxrJfa2D1jvDojaRQ@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 31 quoted lines

>> If we had this:
>>
>>     From github.com:git/git
>>        a7da99ff1b..28d0017056  next                -> origin/*
>>      + e911e946c2...9cc6aca6e9 pu                  -> origin/*  (forced update)
>>        a7da99ff1b..28d0017056  refs/[pull/412/head]  -> origin/*
>>      + 1dbcd06490...6b1f08d3ef refs/[pull/412/merge] -> origin/*  (forced update)
>>      + e911e946c2...9cc6aca6e9 refs/[pull/444/head]  -> origin/*  (forced update)
>>      + 8131760e3b...ed5bbbbcec refs/[pull/444/merge] -> origin/*  (forced update)
>>
>> We could de-duplicate such output. I.e. used [] as "capture" delimiters
>> for the subsequent "*" since "[" and "]" aren't valid in ref names (but
>> "()" and "{}" are!).
>
> First impression, I think the square brackets makes it harder to read
> the left column.
>
> I was going to suggest coloring, which could be used to highlight the
> common parts. But I think that would mess it up even more because it
> kinda steals focus.
>
> Another option is simply display refspec on the right hand side, e.g.
>
>  refs/pull/412/merge -> refs/*:origin/*  (forced update)
>  refs/pull/444/head  -> refs/*:origin/*  (forced update)
>  refs/pull/444/merge -> refs/*:origin/*  (forced update)
>
> This keeps the right column boring and mostly the same without losing
> meaning, while the left column is left untouched. It does make you
> think a bit to find out what the actual ref on the right hand side is
> though.

None of the above, including the existing "origin/*" lets people cut and paste the left-hand-side (which is what is available locally to them) to a command line, e.g. after seeing

     From github.com:git/git
        a7da99ff1b..28d0017056  next                -> origin/*

you cannot append "origin/next" after "git log .." with a few mouse-clicks. As the actual object name after the update appear with the double-dot, "git log ..28d0017056" is also hard to create without dragging a7da99ff1b part from the output.

Having said that, I do not do pointy-and-clicky cut&paste myself, so it would not bother me that much and any of these "compaction" ideas may be OK. Using the refmap notation would start bothering people for perceived repetition of that right-hand-side, though.