Re: Suggestion on git-push --porcelain

[Tay Ray Chuan <rctay89@gmail.com>]

Hi,

On Wed, Feb 10, 2010 at 12:54 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Feb 09, 2010 at 06:57:46PM -0800, Junio C Hamano wrote:
>
>> Tay Ray Chuan <rctay89@gmail.com> writes:
>>
>> >   $ git push --porcelain
>> >   PORCELAIN To git://foo.com/git/myrepo.git
>> >   PORCELAIN uptodate refs/heads/baz:refs/heads/baz 1234ab ba4321
>> >   PORCELAIN nonff refs/heads/bar:refs/heads/bar 2345cd 3456de
>> >
>> > This is an "positive" approach, in the sense that we don't remove
>> > anything from the current output; we just add more printf("PORCELAIN")
>> > lines to wherever is appropriate.
>>
>> Sorry, but I don't see what that would solve.  For example, we used not to
>> give the destination to the standard output stream, but that line carries
>> a necessary information and Larry's series corrects that.
>
> I think he is trying to future-proof any additional output that push (or
> remote helpers) produce.

Yes. By using this (or some other output scheme), we're deliberately
marking out output for porcelain scripts.

> I don't think it is really worth it, though.
> All of that should be going to stderr, and thus would be, at worst,
> noise on the terminal. I don't think it is that hard or error-prone a
> rule to send such cruft to stderr.

on examining the code paths, there's a fair bit of work needed to
ensure this. Apart from transport.c (transport-helper.c and by
extension, remote helpers, looks ok), we would have to look at the
individual builtin-transport implementations for git and bundle.

Also, as you mentioned above, we would also have to take care future
transport implementations send messages in the desired fashion so that
we wouldn't break porcelain scripts. If we have an output scheme, then
such risks are minimized.

-- 
Cheers,
Ray Chuan