Re: Suggestion on git-push --porcelain
- From
Tay Ray Chuan <rctay89@gmail.com>
- Date
- Feb 10, 2010, 11:28 UTC
- Message-ID
- <be6fef0d1002100328g4dac78f6y88497aca791a17fc@mail.gmail.com>
- In-Reply-To
- <20100210045446.GC28526@coredump.intra.peff.net>
Hi,
On Wed, Feb 10, 2010 at 12:54 PM, Jeff King <peff@peff.net> wrote:
Show 19 quoted lines
> 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