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

From: Junio C Hamano <gitster@pobox.com>
Date: May 9, 2022, 17:52 UTC
Message-ID: <xmqqmtfqd25h.fsf@gitster.g>
In-Reply-To: <54aee42d-fe78-eef1-a371-7ca310a9319f@gmail.com>

Philippe Blain <levraiphilippeblain@gmail.com> writes:

Show 5 quoted lines

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

Isn't it where we already are with "remote -v", though? I am not sure addition of excess information that may not be universally useful is a very welcome change, even with "remote -v -v". I am not worried about showing the "list-object-filter", but I worry about managing temptations of future developers to add other stuff.

Show 7 quoted lines

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

Unfortunately, it is not exactly a solution for that to update the tutorial, because experienced and long-time users rightly consider themselves beyond tutorials and sometimes documentation.