From: Tuncer Ayaz Date: Wed, 03 Dec 2008 08:35:48 GMT Subject: Re: [PATCH] Implement rebase -q to fix pull --rebase -q Message-ID: <4ac8254d0812030035n52fde4b3s29c0f525e175f123@mail.gmail.com> In-Reply-To: <7vr64pfyvg.fsf@gitster.siamese.dyndns.org> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano wrote: > "Tuncer Ayaz" 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.