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