"Tuncer Ayaz" <tuncer.ayaz@xxxxxxxxx> 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.
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
would be driving "git pull" from a cron job. IOW, you probably would want
something like "--really-quiet" mode.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
