Philippe Blain <levraiphilippeblain@xxxxxxxxx> 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.
