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