Ideas for even more compact fetch.output=compact output

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 22, 2019, 09:52 UTC
Message-ID: <875ztc5evt.fsf@evledraar.gmail.com>
In-Reply-To: <20190125095122.28719-1-pclouds@gmail.com>

On Fri, Jan 25 2019, Nguyễn Thái Ngọc Duy wrote:

Show 22 quoted lines

> I have a remote named "jch" and it has a branch with the same name. And
> fetch.output is set to "compact". Fetching this remote looks like this
>
>  From https://github.com/gitster/git
>   + eb7fd39f6b...835363af2f jch                -> */jch  (forced update)
>     6f11fd5edb..59b12ae96a  nd/config-move-to  -> jch/*
>   * [new branch]            nd/diff-parseopt   -> jch/*
>   * [new branch]            nd/the-index-final -> jch/*
>
> Notice that the local side of branch jch starts with "*" instead of
> ending with it like the rest. It's not exactly wrong. It just looks
> weird.
>
> This patch changes the find-and-replace code a bit to try finding prefix
> first before falling back to strstr() which finds a substring from left
> to right. Now we have something less OCD
>
>  From https://github.com/gitster/git
>   + eb7fd39f6b...835363af2f jch                -> jch/*  (forced update)
>     6f11fd5edb..59b12ae96a  nd/config-move-to  -> jch/*
>   * [new branch]            nd/diff-parseopt   -> jch/*
>   * [new branch]            nd/the-index-final -> jch/*

This patch works great. The existence of fetch.output=compact had somehow passed me by until a few weeks ago, now using it and it looks great. Thanks.

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

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?