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

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

On Wed, Dec 3, 2008 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> 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?
>
> Not necessarily.  It is entirely up to you.
>
> An important point at this point is that the patch as submitted, without
> such a change, will not be useful to achieve the goal (1) above, because
> it will still be chatty.

I personally don't see a huge point right now in implementing -q
in any more commands.

>>> 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 doubt "the current codebase" has more downside than upside as you seem
> to imply.  The way rebase uses layered set of other commands keeps the

I think it gets "messy" if you start implementing more and more
log levels without an internal consistent logging API. That's
all I wanted to imply :). And this last statement does not
imply that we need such an API. I'm not so sure anymore and
prefer to not work on it without a good plan.

> door open to spread the benefits around.  If you squelch format-patch, you
> would help people who would want to drive it from their cron job (perhaps
> they are on dial-up and they would rather batch things up than running
> format-patch and send-email from their post-receive hook).  If you squelch
> am, you would help people who use it as a part of their mailing list
> scanning software that runs unattended.  Of course, you could choose to
> squelch the "format-patch | am -3" pipeline in one go by redirecting the
> entire pipe to somewhere, instead of giving individual commands --quiet
> option.  If you did so, obviously the benefits won't be spread to users of
> these underlying commands.
>
> But I do not think squelching of these individual commands such as
> format-patch, am, and pull are so useful in the larger picture in the
> context of scripting; see below.
>
>>> 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.
>
> Actually I am not so surprised.

My script is trivial.
It executes the command supplied, captures stderr and stdout to a
temporary file and if and only if the command does not return a
success code the contents of the file are echoed and this leads to
cron mailing the output.

> A cron job that contains a git pull most likely needs to be a script that
> wants to do many other things anyway, such as chdir into the target
> repository, make sure nobody (including yourself) did not by mistake went
> into the repository and made local changes that may interfere with the
> pull and if so abort, perform the pull, noticing its exit status, produce
> the error report and exit if pull fails, validate each new commits the
> pull brought in against some in-house coding standard, run a build test
> (perhaps "make test") if pull succeeded, noticing its exit status, produce
> the error report and exit if the build fails, install the build result if
> build succeeded, and so on.  Individual steps such as "git pull" and "make
> install" are only small self-contained building blocks in such a workflow,
> and it is not unusual for such a script to redirect output from the
> building blocks it uses and produce a summarized report at the very end of
> the run using the redirected output, while emitting messages on its own.
>
> In such an arrangement, having "a bit quieter than usual" option in the
> underlying command, which would be what we would want for these primarily
> interactive commands, is not very useful anyway, because the "quieter"
> output mode may drop some information you might want to include in the
> fuller report when something goes wrong, and filtering such "a bit
> quieter" output takes as much effort as filtering the output from the
> normal mode when there is nothing noteworthy to report and your script
> wants to squelch the output entirely.
>

ACK.