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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Duy Nguyen <pclouds@gmail.com> writes:
>
>>> 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

Aw, I meant right-hand-side (i.e. knife hand, not fork hand).

> 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.