# Re: [PATCH] Make the git-fsck-objects diagnostics more useful 4 messages from 2005-09-20 to 2006-05-29. Participants: Horst von Brand, Petr Baudis, Johannes Schindelin, Michael Richardson. Thread: https://gitlist.dev/t/1890 ## Horst von Brand, 2005-09-20 19:55 Subject: Re: [PATCH] Make the git-fsck-objects diagnostics more useful Message-ID: <200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509201955.j8KJtWAr003157%40laptop11.inf.utfsm.cl In-Reply-To: ``` Petr Baudis wrote: > Actually report what exactly is wrong with the object, instead of an > ambiguous 'bad sha1 file' or such. In places where we already do, unify > the format and clean the messages up. > > Signed-off-by: Petr Baudis > > --- > commit ff0b3368b45a07ac080574eb721a607892413b99 > tree c5e730edddb7679bee63a7d76fb088a7378a9d8b > parent 12913234050c07785b7fc5929e4c8b5f80606609 > author Petr Baudis Tue, 20 Sep 2005 20:54:33 +0200 > committer Petr Baudis Tue, 20 Sep 2005 20:54:33 +0200 > > fsck-objects.c | 82 +++++++++++++++++++++++++++++++++----------------------- > 1 files changed, 48 insertions(+), 34 deletions(-) > > diff --git a/fsck-objects.c b/fsck-objects.c > --- a/fsck-objects.c > +++ b/fsck-objects.c > @@ -20,6 +20,35 @@ static int check_strict = 0; > static int keep_cache_objects = 0; > static unsigned char head_sha1[20]; > > + > +static void objreport(struct object *obj, const char *severity, > + const char *err, va_list params) > +{ > + fprintf(stderr, "%s in %s %s: ", > + severity, obj->type, sha1_to_hex(obj->sha1)); > + vfprintf(stderr, err, params); > + fputs("\n", stderr); > +} Is this legal? I am under the impression you have to call va_start()/va_end() always, even if you just pass the va_list down. The comp.lang.c FAQ agrees with me here... it should be: static void objreport(struct object *obj, const char *severity, const char *err, ...) { va_list params; fprintf(stderr, "%s in %s %s: ", severity, obj->type, sha1_to_hex(obj->sha1)); va_start(params, err); vfprintf(stderr, err, params); va_end(params); fputs("\n", stderr); } [Yes, I know. "We all are using gcc and glibc on Linux". But anyway.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ``` ## Petr Baudis, 2005-09-21 08:19 Subject: Re: [PATCH] Make the git-fsck-objects diagnostics more useful Message-ID: <20050921081954.GB24902@pasky.or.cz> URL: https://gitlist.dev/e/20050921081954.GB24902%40pasky.or.cz In-Reply-To: <200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl> ``` Dear diary, on Tue, Sep 20, 2005 at 09:55:32PM CEST, I got a letter where Horst von Brand told me that... > > +static void objreport(struct object *obj, const char *severity, > > + const char *err, va_list params) > > +{ > > + fprintf(stderr, "%s in %s %s: ", > > + severity, obj->type, sha1_to_hex(obj->sha1)); > > + vfprintf(stderr, err, params); > > + fputs("\n", stderr); > > +} > > Is this legal? I am under the impression you have to call > va_start()/va_end() always, even if you just pass the va_list down. va_list will probably be/contain some pointer, and with va_start() you "seed" it to point at the stack after the given parameter and slurp the additional function parameters from there. If you already have it initialized, va_start() makes no sense. > The comp.lang.c FAQ agrees > with me here... it should be: That says nothing about passing va_list down. > static void objreport(struct object *obj, const char *severity, > const char *err, ...) > { > va_list params; > > fprintf(stderr, "%s in %s %s: ", > severity, obj->type, sha1_to_hex(obj->sha1)); > va_start(params, err); > vfprintf(stderr, err, params); > va_end(params); > fputs("\n", stderr); > } How do you then call objreport() ? params would contain another va_list if you called it the same as before, which would probably surprise vfprintf() a bit. BTW, we do the same in usage.c. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Johannes Schindelin, 2005-09-21 09:13 Subject: Re: [PATCH] Make the git-fsck-objects diagnostics more useful Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0509211112320.12989%40wgmdd8.biozentrum.uni-wuerzburg.de In-Reply-To: <200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl> ``` Hi, On Tue, 20 Sep 2005, Horst von Brand wrote: > [Yes, I know. "We all are using gcc and glibc on Linux". But anyway.] No. "We not all don't." Ciao, Dscho ``` ## Michael Richardson, 2006-05-29 16:03 Subject: Re: [PATCH] git-receive-pack needs to set umask(2) Message-ID: <18609.1148918620@sandelman.ottawa.on.ca> URL: https://gitlist.dev/e/18609.1148918620%40sandelman.ottawa.on.ca In-Reply-To: ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Petr" == Petr Baudis writes: Petr> The object database is considered "append-only" unless you do Petr> git-prune (and you should better not let anyone do that), thus Petr> it's enough if you set all directories group-writable. Other Exactly, you have to do that. And only the owner can change the modes, thus, unless all users have their umask set up right, someone gets toasted. Since the directories are created on the fly, they need to be created with the right permissions. Petr> than access the object database, the users probably only want Petr> to update the refs - the solution is to make refs/heads/ and Petr> refs/tags/ group-writable and setgid. This is also what Petr> git-init-db --shared (or tools like cg-admin-setuprepo) should Petr> already set up for you. Petr> So, what did break? Never heard of "git-init-db --shared". > A shared repository allows users belonging to the same group to push > into that repository. When specifying `--shared` the config variable > "core.sharedRepository" is set to 'true' so that directories under > `$GIT_DIR` are made group writable (and g+sx, since the git group may > be not the primary group of all users). That would seem to be the right thing. Seems it was added in December. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRHsbW4CLcPvd0N1lAQKa/gf+MF93+zbNnmqpysWMmYPVhW6HvU6XFyCQ KyTfA7dxVX3tS9coSAcT73IX659umMz1MkyG7YR4ISFLlhLmdthq6l/ETueTZPVw SgTSEU9TT2sM+gjtzy6v1wGQJAXJxYw6kJgKOFgCfyIPsb7EZWyQBmZLiNU0omnv gkV8Ja5pJPTNHcinzzNyg8LIm0j55cS9OG9XQrXm46q+9OX+y39BoxGnz3Guzmry yzfx1ipDuW54QCzKRyBpwt7/1LBfk/eJAH0wP9IAA4qz39+OA2yz8fTMvHDB1a6V H18SkBENb6ZllGovu60IUgJCKy2sizGkBGUax9ec2ByAzHL1al3W3g== =arDu -----END PGP SIGNATURE----- ```