Re: [PATCH v4] builtin/remote.c: teach `-v` to list filters for promisor remotes

From: Philippe Blain <levraiphilippeblain@gmail.com>
Date: May 9, 2022, 17:01 UTC
Message-ID: <54aee42d-fe78-eef1-a371-7ca310a9319f@gmail.com>
In-Reply-To: <Ynk0mADTSJU/xVUd@nand.local>

Hi Taylor,

Le 2022-05-09 à 11:34, Taylor Blau a écrit :

Show 17 quoted lines

> On Mon, May 09, 2022 at 11:32:48AM +0000, Abhradeep Chakraborty via GitGitGadget wrote:
>> From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
>>
>> `git remote -v` (`--verbose`) lists down the names of remotes along with
>> their URLs. It would be beneficial for users to also specify the filter
>> types for promisor remotes. Something like this -
> 
> This version looks like it has addressed many (all?) of the comments
> previously discussed during review. On a quick scan, the code and tests
> look good to my eyes, too.
> 
> But there was a good question raised by Phillip in
> 
>     https://lore.kernel.org/git/ab047b4b-6037-af78-1af6-ad35ac6d7c90@iee.email/
> 
> that I didn't see addressed in your response, which was "why not put
> this behind a new `--show-partial-filter` option"?

I originally opened the issue on GGG that this series adresses. My justification, and asnwer to that question, is simple: 'git remote -v', for me, is a way to ask Git to give me all the information it knows about my configured remotes. That's why I thought that it would be really nice if partial clones filters would be shown.

After all, 'git remote' is listed in the 'porcelain' section of the Git commands [1], and isn't the goal of declaring commands "porcelain" that we can make their output more useful to the users without worrying as much about backwards compatibility than with plumbing commands?

Show 6 quoted lines

> I share (what I think is) Junio's feeling that having information that
> is readily available from e.g., running "git config --get
> remote.<name>.partialObjectFilter" seems redundant. I could understand
> forcing a user to know the config key's name feels like a hurdle. But
> cluttering the output of `git remote -v` seems like the wrong solution
> to that hurdle.

As I said above, I have 'git rem' (my alias for 'git remote -v') in my muscle memory and use it when I want to have an outline of my configured remotes. I think it would be really easier to add the filters info to the existing output. It's really faster to type than using 'git config', and you do not have to remember which remote name to query. I think "clutter" is a little strong word here :)

> But I can see where it _would_ be useful. So it would be nice to be able
> to turn the extra output on in those cases, but _only_ those cases, and
> a flag would be a nice way to go about doing that.

If really this topic is blocked by "we do not want to change the default output of 'git remote -v'", then I agree it would be nice to be able to set 'remote.showFilters' (or similar) to get such output, I agree.

Or, making 'git remote' act like 'git branch' and accept a second '-v', i.e. 'git remote -vv' would list filters (then I would just adjust my alias :P). Then we can outright declare "the output of 'git remote -vv' is subject to future changes to show more useful information", or similar, so we do not have to do the same dance the next time we want to add some other info.

The downside of hiding such new features behing config values or additional flags is that it really, really limits their discoverability. This is something that I often think about and think we should really do better in Git, in general. For example, features like 'remote.pushDefault' or the 'diff=*' attribute for language-aware hunk headers (and funcname-limited log/blame etc) are immensely useful, but often even experienced and long-time Git users do not even know they exist, because they are not covered in "regular" Git tutorials...

Cheers,

Philippe.

[1] https://git-scm.com/docs/git#Documentation/git.txt-ahrefdocsgit-remotegit-remote1a