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.

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

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

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

> Jeff King <peff@peff.net> 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.

> On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> 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".
> 
> 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.

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

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

> David Aguilar <davvid@gmail.com> writes:
> 
> > 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.
> 
> > 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.
> 
> > 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).
> 
> >> > 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.
> >