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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 22, 2019 at 4:52 PM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> Just using this as a bounce-off point for a related discussion, one case
> where I still see duplicates is things like:
>
>     From github.com:git/git
>        a7da99ff1b..28d0017056  next                -> origin/*
>      + e911e946c2...9cc6aca6e9 pu                  -> origin/*  (forced update)
>        a7da99ff1b..28d0017056  refs/pull/412/head  -> origin/pull/412/head
>      + 1dbcd06490...6b1f08d3ef refs/pull/412/merge -> origin/pull/412/merge  (forced update)
>      + e911e946c2...9cc6aca6e9 refs/pull/444/head  -> origin/pull/444/head  (forced update)
>      + 8131760e3b...ed5bbbbcec refs/pull/444/merge -> origin/pull/444/merge  (forced update)
>
> I.e. the duplicate strings for the "pull" namespace I'm fetching.
>
> Now, there's no room with the current syntax to represent that
> unambiguously, I started to patch it, but wasn't sure I liked the syntax
> I came up with.
>
> This is also one of the rare cases where bikeshedding the idea can
> productively done without a patch so I thought I'd start that discussion
> first.
>
> 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.

> Or maybe more generally using it consistently throughout, also for next/pu:
>
>     From github.com:git/git
>        a7da99ff1b..28d0017056  [next]                -> origin/*
>      + e911e946c2...9cc6aca6e9 [pu]                  -> origin/*  (forced update)
>        a7da99ff1b..28d0017056  refs/[pull/412/head]  -> origin/*
>     [...]
>
> The things that suck the most about this are that you can no longer
> copy/paste the ref on the LHS as-is, and that it'll only show up in rare
> cases, so it'll probably confuse even experienced users.
>
> What do you think?



-- 
Duy




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux