Re: Improving the git remote command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Aguilar <davvid@xxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]