All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Aguilar <davvid@gmail.com>
Cc: "Jeff King" <peff@peff.net>,
	"Philippe Vaucher" <philippe.vaucher@gmail.com>,
	"Rémy Hubscher" <hubscher.remy@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Improving the git remote command
Date: Wed, 27 Aug 2014 13:35:44 -0700	[thread overview]
Message-ID: <xmqqegw1d61r.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140827163617.GA66615@gmail.com> (David Aguilar's message of "Wed, 27 Aug 2014 09:36:18 -0700")

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

  reply	other threads:[~2014-08-27 20:36 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
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 [this message]
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=xmqqegw1d61r.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hubscher.remy@gmail.com \
    --cc=peff@peff.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.