# Silent maintenance 9 messages from 2010-08-14 to 2010-08-15. Participants: Enrico Weigelt, Ævar Arnfjörð Bjarmason, Valeo de Vries, Jonathan Nieder, Jeff King. Thread: https://gitlist.dev/t/24740 ## Enrico Weigelt, 2010-08-14 13:11 Subject: Silent maintenance Message-ID: <20100814131156.GA24769@nibiru.local> URL: https://gitlist.dev/e/20100814131156.GA24769%40nibiru.local ``` Hi, are there some flags to make the maintenance commands like git-repack and git-gc silent, so they only output errors ? thx -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- ``` ## Ævar Arnfjörð Bjarmason, 2010-08-14 13:26 Subject: Re: Silent maintenance Message-ID: URL: https://gitlist.dev/e/AANLkTing1Lgt7JEeg9SY4J2Q3i_cDuK5uJhmd%3D6DbzuZ%40mail.gmail.com In-Reply-To: <20100814131156.GA24769@nibiru.local> ``` On Sat, Aug 14, 2010 at 13:11, Enrico Weigelt wrote: > are there some flags to make the maintenance commands like > git-repack and git-gc silent, so they only output errors ? With Git you should check the exit code of commands, not if they're silent or not. Are you running something via cron? ``` ## Valeo de Vries, 2010-08-14 16:33 Subject: Re: Silent maintenance Message-ID: URL: https://gitlist.dev/e/AANLkTimZ4df7wVXSGdNm%2BvWgAuPVDcUupxEvn9FByx%3DP%40mail.gmail.com In-Reply-To: <20100814131156.GA24769@nibiru.local> ``` On 14 August 2010 14:11, Enrico Weigelt wrote: > Hi, > > are there some flags to make the maintenance commands like > git-repack and git-gc silent, so they only output errors ? Just redirect stdout to /dev/null and check git's return status, as Ævar said. Valeo ``` ## Ævar Arnfjörð Bjarmason, 2010-08-14 16:41 Subject: Re: Silent maintenance Message-ID: URL: https://gitlist.dev/e/AANLkTi%3D%2BveDhBEt-tK_qaXhvMVmRCZtW7%2BO6ig3ujASz%40mail.gmail.com In-Reply-To: ``` On Sat, Aug 14, 2010 at 16:33, Valeo de Vries wrote: > On 14 August 2010 14:11, Enrico Weigelt wrote: >> Hi, >> >> are there some flags to make the maintenance commands like >> git-repack and git-gc silent, so they only output errors ? > > Just redirect stdout to /dev/null and check git's return status, as Ęvar said. It's better to not redirect anything, set a trap that checks if anything exited with non-zero, and then look at all the output if anything fails. ``` ## Jonathan Nieder, 2010-08-14 21:05 Subject: Re: Silent maintenance Message-ID: <20100814210556.GB2372@burratino> URL: https://gitlist.dev/e/20100814210556.GB2372%40burratino In-Reply-To: <20100814131156.GA24769@nibiru.local> ``` Enrico Weigelt wrote: > are there some flags to make the maintenance commands like > git-repack and git-gc silent, so they only output errors ? Does --quiet work? If not, patches would be welcome. ``` ## Ævar Arnfjörð Bjarmason, 2010-08-14 21:41 Subject: Re: Silent maintenance Message-ID: URL: https://gitlist.dev/e/AANLkTimLHand0g965TJmk%3DY4Q%2B0uTFovZZRZXf9Fx4UB%40mail.gmail.com In-Reply-To: <20100814210556.GB2372@burratino> ``` On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote: > Enrico Weigelt wrote: > >> are there some flags to make the maintenance commands like >> git-repack and git-gc silent, so they only output errors ? > > Does --quiet work?  If not, patches would be welcome. I intentionally neglected to mention that. That inevitably leads to cases where something fails, but you didn't record the output. Instead (copy/paste from a recent post of mine to an unrelated mailing list, funny how these things come up at the same time), do: Just install this: http://search.cpan.org/dist/App-Cronjob/ Then put something like this in your crontab: @daily cronjob -E -j josm-build -E /path/to/build.sh cronjob(1) will consume all the output, and either print it all or nothing, depending on the exit code of the program it's running. If you're running a POSIX shell script you can add this to the top of the script: # Exit on errors trap 'fail' ERR fail () { code=$? echo "Failed with exit code $code" exit 1 } Then you don't have to check the exit code of everything individually. I use this for all my cronjobs, see e.g. http://github.com/avar/openstreetmap-mirror for an example, it's what I use to get E-Mails when the JOSM GitHub mirror fails, but *only* when it fails. ``` ## Jeff King, 2010-08-14 22:04 Subject: Re: Silent maintenance Message-ID: <20100814220410.GA16592@coredump.intra.peff.net> URL: https://gitlist.dev/e/20100814220410.GA16592%40coredump.intra.peff.net In-Reply-To: ``` On Sat, Aug 14, 2010 at 09:41:44PM +0000, Ævar Arnfjörð Bjarmason wrote: > On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote: > > Enrico Weigelt wrote: > > > >> are there some flags to make the maintenance commands like > >> git-repack and git-gc silent, so they only output errors ? > > > > Does --quiet work?  If not, patches would be welcome. > > I intentionally neglected to mention that. That inevitably leads to > cases where something fails, but you didn't record the output. I'm confused. Isn't the point of quiet to silence all of the cruft, and leave only actual errors? $ git gc Counting objects: 128, done. Compressing objects: 100% (49/49), done. Writing objects: 100% (128/128), done. Total 128 (delta 71), reused 121 (delta 68) $ git gc --quiet $ chmod -w .git/objects/pack $ git gc --quiet fatal: Unable to create temporary file: Permission denied error: failed to run repack Isn't that what the OP wanted? > cronjob(1) will consume all the output, and either print it all or > nothing, depending on the exit code of the program it's running. That is a good solution for broken programs that have no "print only errors" mode, but I don't think git is one of those (and if it is, we should fix it). -Peff ``` ## Ævar Arnfjörð Bjarmason, 2010-08-15 00:21 Subject: Re: Silent maintenance Message-ID: URL: https://gitlist.dev/e/AANLkTim1HL_WH_ShxNYXmsSnbMNq7%3DC7oj46qav2OQe1%40mail.gmail.com In-Reply-To: <20100814220410.GA16592@coredump.intra.peff.net> ``` On Sat, Aug 14, 2010 at 22:04, Jeff King wrote: > On Sat, Aug 14, 2010 at 09:41:44PM +0000, Ævar Arnfjörð Bjarmason wrote: > >> On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote: >> > Enrico Weigelt wrote: >> > >> >> are there some flags to make the maintenance commands like >> >> git-repack and git-gc silent, so they only output errors ? >> > >> > Does --quiet work?  If not, patches would be welcome. >> >> I intentionally neglected to mention that. That inevitably leads to >> cases where something fails, but you didn't record the output. > > I'm confused. Isn't the point of quiet to silence all of the cruft, and > leave only actual errors? > >  $ git gc >  Counting objects: 128, done. >  Compressing objects: 100% (49/49), done. >  Writing objects: 100% (128/128), done. >  Total 128 (delta 71), reused 121 (delta 68) > >  $ git gc --quiet > >  $ chmod -w .git/objects/pack >  $ git gc --quiet >  fatal: Unable to create temporary file: Permission denied >  error: failed to run repack > > Isn't that what the OP wanted? Maybe, personally I prefer to get all or nothing. If you specify --quiet you'll only get errors, so it doesn't give you much context. But if you use cronjob(1) you can see at a glance the normal output of all the successfully executed commands that led up to your failure. E.g. the output of a successful "cherry-pick" right before a failing merge can be really helpful to see the state of the failing program. ``` ## Enrico Weigelt, 2010-08-15 13:12 Subject: Re: Silent maintenance Message-ID: <20100815131200.GA27637@nibiru.local> URL: https://gitlist.dev/e/20100815131200.GA27637%40nibiru.local In-Reply-To: ``` * Ævar Arnfjörð Bjarmason wrote: Hi folks, > Maybe, personally I prefer to get all or nothing. If you specify > --quiet you'll only get errors, so it doesn't give you much > context. But if you use cronjob(1) you can see at a glance the normal > output of all the successfully executed commands that led up to your > failure. for my purpose, this should be sufficient, as I'll have to step in manually in case of errors anyways. thx to all. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- ```