Improving the git remote command

I'd like to add a list parameter to the git remote command.

We already have:

- git remote add
- git remote rename
- git remote delete

I often write git remote list before finaly using git remote -v but it isn't intuitive.

I am proposing to add git remote list as a shortcut for git remote -v

Perhaps "-v" should have been the default all along. I do not use "git remote" myself, so I don't know if "-v" is what most people use. But changing the output of "git remote" now is probably a bad thing (I expect some people may depend on parsing it to get the list of remotes; they should probably use the git-config plumbing to do the same thing, but it's actually rather tricky to do it that way).

Quoted 6 lines

Perhaps "-v" should have been the default all along. I do not use "git remote" myself, so I don't know if "-v" is what most people use. But changing the output of "git remote" now is probably a bad thing (I expect some people may depend on parsing it to get the list of remotes; they should probably use the git-config plumbing to do the same thing, but it's actually rather tricky to do it that way).

Just to be clear, the proposal is not about changing the output of "git remote".

Anyway, it got me curious about other git commands reguarding "list", and I was very surprised because I couldn't find another one. I mean "git remote" actually behaves like "git branch" and "git tag". I have no clue why I expect "list" to work with "git remote".

It's probably because "git branch" and "git tag" expect a name, and there "list" can only be expressed by "no name" or with some flags. On the other hand, "git remote" expects a subcommand (add, delete, etc) and there what logically maps to "list" is the subcommand "list", "no name" being more expected to produce a list of the subcommands.

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

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

Quoted 13 lines · Jeff King

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

Quoted 2 lines

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.

Quoted 15 lines · Junio C Hamano

Quoted 13 lines · Jeff King

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

Quoted 8 lines

Quoted 2 lines

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

Yeah, I touched on that earlier. I would personally consider "git remote" to be a porcelain, and "git config" to be the appropriate plumbing for accessing those values. However, it's a little tricky to robustly get the list of remotes with "git config". So I would not be surprised if scripts have used "git remote" to do the same thing (I know for a fact that some internal scripts at GitHub did this, though I recently cleaned them up so I do not have a vested interest either way at this point).

That does not mean those scripts are right and we cannot change things, but it may be a matter of practicality.

Quoted 6 lines

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, I'd agree with that.

We have some internal scripts at Disney Animation that rely on "git remote" output so I would vote for #3 personally as well.

I know that "git config" is porcelain, and I can get remote.(.*).url, but that's not obvious and I highly doubt that anyone does that.

What if we said that "git remote list --porcelain" == "git remote" and then just leave "git remote" output as-is so that we don't have to have a flag day when we break people's scripts?

Quoted 8 lines

Quoted 6 lines

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, I'd agree with that.

Ditto.

Quoted 2 lines · David Aguilar

We have some internal scripts at Disney Animation that rely on "git remote" output so I would vote for #3 personally as well.

I take it that you mean you would vote _against_ #3 which will break the expectation.

Quoted 2 lines

I know that "git config" is porcelain, and I can get remote.(.*).url, but that's not obvious and I highly doubt that anyone does that.

Perhaps that is something worth fixing.

Quoted 3 lines

What if we said that "git remote list --porcelain" == "git remote" and then just leave "git remote" output as-is so that we don't have to have a flag day when we break people's scripts?

I suspect that it is not likely a workable solution. The commands being Porcelain by definition means that people aimed to make their output consumable by humans, and the current "git remote", which may be what your script happens to use, is not by design the best representation of the information for all the script writers to want to call _good_.

If we were to do "git remote list", I'd imagine it would be far more useful to have --format="<format specifiers>" option so that you can do something like

	git remote list --format="%(name) %(url) (%(direction))"

Then scripts can explicitly ask for what they want and have less chance of getting broken (I say "less" because what %(specifier) stands for could be changed either to fix mistakes or by mistake).

Quoted 9 lines

Quoted 8 lines

Quoted 6 lines

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, I'd agree with that.

I often write git remote list before finaly using git remote -v but it isn't intuitive.

I am proposing to add git remote list as a shortcut for git remote -v