Jeff King <peff@xxxxxxxx> writes:
> ... But we are left with three options:
>
> 1. Add "git remote list" with verbose output. This is bad because it
> differs gratuitously from "git remote".
>
> 2. Add "git remote list" with non-verbose output. This is good because
> it means "git remote" is just a shortcut for "git remote list",
> which is consistent with other parts of git. But it is potentially
> bad if "-v" is a better output format.
>
> 3. Add "git remote list" with verbose output, and tweak "git remote"
> to match. This is bad because it breaks backwards compatibility.
>
> The proposal is for (1). I think we agree that (3) is out. The question
> is whether (1) or (2) is the least bad.
I would imagine that those who want list of remotes programatically
would read from "git config" output and it would be with less
friction to change the output from "git remote", a command that is
solely to cater to end-user humans, to suit people's needs, so I am
not sure if (3) is immediately "out".
Having said that, my preference is
0. Do nothing, but document the "default to listing" better if
needed.
and then 2. above, and then 1.
> Yeah. Branch and tag need dashed subcommands because otherwise it is
> ambiguous with creating tag called "list", functionality that existed
> before "--list" was added. Git-remote was defined with subcommands from
> day one, so it can get away with it. Git-stash is sort of in the
> category as git-remote there, except that "save" can actually take an
> argument. So to provide it you can't say "git stash foobar", but instead
> have to say "git stash save foobar" (it actually used to allow the
> former, but you can imagine the annoyance when you typo "git stash
> lsit").
Yeah, and there also is this one:
http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html