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

[Junio C Hamano <gitster@pobox.com>]

Philippe Blain <levraiphilippeblain@gmail.com> writes:

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

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