git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Philippe Vaucher <philippe.vaucher@gmail.com>
Cc: "Rémy Hubscher" <hubscher.remy@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Improving the git remote command
Date: Tue, 26 Aug 2014 12:37:41 -0400	[thread overview]
Message-ID: <20140826163741.GA14983@peff.net> (raw)
In-Reply-To: <CAGK7Mr7BPvV6oO_t4x_1m9sDtWBgPWUqDq+3kZx6rVYAhY+wqA@mail.gmail.com>

On Tue, Aug 26, 2014 at 06:19:20PM +0200, Philippe Vaucher wrote:

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

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

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

Branch and tag take "--list". Remote is the odd one out in that its
subcommands do not have dashes. git-stash also takes commands without
dashes (and has a list command), but its default mode is to create a
stash, not to list.

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

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

-Peff

  reply	other threads:[~2014-08-26 16:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26  9:29 Improving the git remote command Rémy Hubscher
2014-08-26 10:05 ` Philippe Vaucher
2014-08-26 12:40 ` Jeff King
2014-08-26 16:19   ` Philippe Vaucher
2014-08-26 16:37     ` Jeff King [this message]
2014-08-26 17:24       ` Junio C Hamano
2014-08-26 17:33         ` Jeff King
2014-08-27 16:36           ` David Aguilar
2014-08-27 20:35             ` Junio C Hamano
2014-08-27 21:22               ` Keller, Jacob E

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140826163741.GA14983@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=hubscher.remy@gmail.com \
    --cc=philippe.vaucher@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).