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

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

On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> 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.
>
> Ahh, ok, if this is for cron jobs, then it is understandable that:
>
>  (1) You may want a successful "git pull" or "git pull --rebase" to be
>     absolutely silent about what it did; and
>
>  (2) A failed "git pull" and "git pull --rebase" that produces information
>     other than the fact it failed would not help you, the receiver of a
>     cron job report, very much.  You would go to the repository when it
>     fails, reset the mess away, and then do the pull or pull-rebase
>     yourself manually anyway.
>
> If that is the motivation behind the series, I think you would really want
> to squelch output from "format-patch | am -3" pipeline.

You mean I should follow this path and produce a patch series instead?

> Another thing to consider is that, unlike simple single-operation commands
> such as "mv" or "cp" you mentioned, what "git pull" does is much more
> involved and has many different failure modes, so you cannot compare them
> fairly.  Simple commands can have a single "quiet" level, but I have a
> feeling that there is a difference between "quiet mode" I expect when I am
> running "git pull" interactively and "quiet mode" I would want when I

We have the same expectation here and IDE writers also seem to expect that.

> would be driving "git pull" from a cron job.  IOW, you probably would want
> something like "--really-quiet" mode.

Yeah, it gets messy and in the current codebase. I am also not sure whether
the effort/benefit ratio is good enough.

> I would write such a cron-job script to capture the log and send it only
> upon failure from the underlying command if I were doing this myself,
> though.

This is the way I do it now and I'm surprised I found no other simple way
than writing a wrapper script for it. At least not with vixie-cron.