Silent maintenance

Silent maintenance

[Enrico Weigelt]

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
----------------------------------------------------------------------

Re: Silent maintenance

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 14, 2010 at 13:11, Enrico Weigelt <weigelt@metux.de> 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?

Re: Silent maintenance

[Valeo de Vries]

On 14 August 2010 14:11, Enrico Weigelt <weigelt@metux.de> 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

Re: Silent maintenance

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 14, 2010 at 16:33, Valeo de Vries <valeo@valeo.co.cc> wrote:
> On 14 August 2010 14:11, Enrico Weigelt <weigelt@metux.de> 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.

Re: Silent maintenance

[Jonathan Nieder]

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.

Re: Silent maintenance

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder <jrnieder@gmail.com> 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.

Re: Silent maintenance

[Jeff King]

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 <jrnieder@gmail.com> 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

Re: Silent maintenance

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 14, 2010 at 22:04, Jeff King <peff@peff.net> 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 <jrnieder@gmail.com> 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.

Re: Silent maintenance

[Enrico Weigelt]

* Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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
----------------------------------------------------------------------