Junio C Hamano <gits...@pobox.com> writes:
> Duy Nguyen <pclo...@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.
