Re: [PATCH] Implement rebase -q to fix pull --rebase -q

["Tuncer Ayaz" <tuncer.ayaz@gmail.com>]

On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> This is needed on top of the fetch/pull -q/-v changes
>> to make
>> $ git pull --rebase -q
>> as quiet as expected.
>
> I am not sure if this is worth it, in the sense that it is not really
> quiet enough (iow, it is not what I expect even though you claim "as

Junio, sorry for using 'expected'.
I thought about the wording while writing and had a feeling that 'expected'
may be too strong as it's my opinion only. I should have listened to myself :).

> expected" here), and in another sense that making it really quiet may not
> be what we want anyway.

I mainly use -q in automation where I only want output if something
goes wrong. Just like good old cp or mv do.
Do you think this is the wrong way to go?

> How are you dealing with messages from the actual replaying of each local
> commit on top of what is fetched?  In order to be able to tell where you
> are when one of them fail in conflicts, you cannot stay silent while doing
> so.

Fair point.

Log messages that are of importance to a failure should ideally be sent to
stderr but I think caching log messages for the failure case would
over-complicate
much of the code and is not worth it. Also you may not always know which part
of stdout messages are useful for the failure case and not getting the
same messages
on a rerun for many commands makes this hard to trace back, yeah.

As we've quietened pull/fetch/clone in a major already I am OK with leaving this
change out.
I'm definitely not advocating adding/changing anything when it's not clear we
want the changed behavior. It's easier to keep out than to remove it
later on :).