On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "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. 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. -- 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
