{"thread":{"id":"1890","subject":"Re: [PATCH] Make the git-fsck-objects diagnostics more useful","startedAt":"2005-09-20T19:55:32Z","lastAt":"2006-05-29T16:03:40Z","messageCount":4,"participants":["Horst von Brand","Petr Baudis","Johannes Schindelin","Michael Richardson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"9013","messageId":"200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl","threadId":"1890","inReplyTo":"pasky@ucw.cz","subject":"Re: [PATCH] Make the git-fsck-objects diagnostics more useful","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-20T19:55:32Z","receivedAt":"2005-09-20T19:55:32Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Petr Baudis wrote:\n> Actually report what exactly is wrong with the object, instead of an\n> ambiguous 'bad sha1 file' or such. In places where we already do, unify\n> the format and clean the messages up.\n> \n> Signed-off-by: Petr Baudis \n> \n> ---\n> commit ff0b3368b45a07ac080574eb721a607892413b99\n> tree c5e730edddb7679bee63a7d76fb088a7378a9d8b\n> parent 12913234050c07785b7fc5929e4c8b5f80606609\n> author Petr Baudis Tue, 20 Sep 2005 20:54:33 +0200\n> committer Petr Baudis Tue, 20 Sep 2005 20:54:33 +0200\n> \n> fsck-objects.c | 82 +++++++++++++++++++++++++++++++++-----------------------\n> 1 files changed, 48 insertions(+), 34 deletions(-)\n> \n> diff --git a/fsck-objects.c b/fsck-objects.c\n> --- a/fsck-objects.c\n> +++ b/fsck-objects.c\n> @@ -20,6 +20,35 @@ static int check_strict = 0;\n> static int keep_cache_objects = 0; \n> static unsigned char head_sha1[20];\n> \n> +\n> +static void objreport(struct object *obj, const char *severity,\n> + const char *err, va_list params)\n> +{\n> +\tfprintf(stderr, \"%s in %s %s: \",\n> +\t severity, obj->type, sha1_to_hex(obj->sha1));\n> +\tvfprintf(stderr, err, params);\n> +\tfputs(\"\\n\", stderr);\n> +}\n\nIs this legal? I am under the impression you have to call\nva_start()/va_end() always, even if you just pass the va_list down.\n\nThe comp.lang.c FAQ agrees\nwith me here... it should be:\n\nstatic void objreport(struct object *obj, const char *severity,\n const char *err, ...)\n{\n\tva_list params;\n\t\n\tfprintf(stderr, \"%s in %s %s: \",\n\t severity, obj->type, sha1_to_hex(obj->sha1));\n\tva_start(params, err);\n vfprintf(stderr, err, params);\t\n\tva_end(params);\n\tfputs(\"\\n\", stderr);\n}\n\n[Yes, I know. \"We all are using gcc and glibc on Linux\". But anyway.]\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"9024","messageId":"20050921081954.GB24902@pasky.or.cz","threadId":"1890","inReplyTo":"200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Make the git-fsck-objects diagnostics more useful","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-21T08:19:54Z","receivedAt":"2005-09-21T08:19:54Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 09:55:32PM CEST, I got a letter\nwhere Horst von Brand told me that...\n> > +static void objreport(struct object *obj, const char *severity,\n> > + const char *err, va_list params)\n> > +{\n> > +\tfprintf(stderr, \"%s in %s %s: \",\n> > +\t severity, obj->type, sha1_to_hex(obj->sha1));\n> > +\tvfprintf(stderr, err, params);\n> > +\tfputs(\"\\n\", stderr);\n> > +}\n> \n> Is this legal? I am under the impression you have to call\n> va_start()/va_end() always, even if you just pass the va_list down.\n\nva_list will probably be/contain some pointer, and with va_start() you\n\"seed\" it to point at the stack after the given parameter and slurp the\nadditional function parameters from there. If you already have it\ninitialized, va_start() makes no sense.\n\n> The comp.lang.c FAQ agrees\n> with me here... it should be:\n\nThat says nothing about passing va_list down.\n\n> static void objreport(struct object *obj, const char *severity,\n> const char *err, ...)\n> {\n> \tva_list params;\n> \t\n> \tfprintf(stderr, \"%s in %s %s: \",\n> \t severity, obj->type, sha1_to_hex(obj->sha1));\n> \tva_start(params, err);\n> vfprintf(stderr, err, params);\t\n> \tva_end(params);\n> \tfputs(\"\\n\", stderr);\n> }\n\nHow do you then call objreport() ? params would contain another va_list\nif you called it the same as before, which would probably surprise\nvfprintf() a bit.\n\nBTW, we do the same in usage.c.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9027","messageId":"Pine.LNX.4.63.0509211112320.12989@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1890","inReplyTo":"200509201955.j8KJtWAr003157@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Make the git-fsck-objects diagnostics more useful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-21T09:13:14Z","receivedAt":"2005-09-21T09:13:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 Sep 2005, Horst von Brand wrote:\n\n> [Yes, I know. \"We all are using gcc and glibc on Linux\". But anyway.]\n\nNo. \"We not all don't.\" \n\nCiao,\nDscho\n"},{"id":"20893","messageId":"18609.1148918620@sandelman.ottawa.on.ca","threadId":"1890","inReplyTo":"pasky@ucw.cz","subject":"Re: [PATCH] git-receive-pack needs to set umask(2)","fromName":"Michael Richardson","fromEmail":"mcr@sandelman.ottawa.on.ca","sentAt":"2006-05-29T16:03:40Z","receivedAt":"2006-05-29T16:03:40Z","isPatch":true,"sender":{"key":"mcr@sandelman.ottawa.on.ca","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n\n>>>>> \"Petr\" == Petr Baudis writes:\n Petr> The object database is considered \"append-only\" unless you do\n Petr> git-prune (and you should better not let anyone do that), thus\n Petr> it's enough if you set all directories group-writable. Other\n\n Exactly, you have to do that. And only the owner can change the modes,\nthus, unless all users have their umask set up right, someone gets toasted.\n Since the directories are created on the fly, they need to be created\nwith the right permissions. \n\n Petr> than access the object database, the users probably only want\n Petr> to update the refs - the solution is to make refs/heads/ and\n Petr> refs/tags/ group-writable and setgid. This is also what\n Petr> git-init-db --shared (or tools like cg-admin-setuprepo) should\n Petr> already set up for you.\n\n Petr> So, what did break?\n\n Never heard of \"git-init-db --shared\".\n\n> A shared repository allows users belonging to the same group to push\n> into that repository. When specifying `--shared` the config variable\n> \"core.sharedRepository\" is set to 'true' so that directories under\n> `$GIT_DIR` are made group writable (and g+sx, since the git group may\n> be not the primary group of all users). \n\n That would seem to be the right thing.\n Seems it was added in December.\n\n- -- \n] ON HUMILITY: to err is human. To moo, bovine. | firewalls [\n] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[\n] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[\n] panic(\"Just another Debian GNU/Linux using, kernel hacking, security guy\"); [\n\n \"The Microsoft _Get the Facts CD_ does not work on Linux.\" - orospakr\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2.2 (GNU/Linux)\nComment: Finger me for keys\n\niQEVAwUBRHsbW4CLcPvd0N1lAQKa/gf+MF93+zbNnmqpysWMmYPVhW6HvU6XFyCQ\nKyTfA7dxVX3tS9coSAcT73IX659umMz1MkyG7YR4ISFLlhLmdthq6l/ETueTZPVw\nSgTSEU9TT2sM+gjtzy6v1wGQJAXJxYw6kJgKOFgCfyIPsb7EZWyQBmZLiNU0omnv\ngkV8Ja5pJPTNHcinzzNyg8LIm0j55cS9OG9XQrXm46q+9OX+y39BoxGnz3Guzmry\nyzfx1ipDuW54QCzKRyBpwt7/1LBfk/eJAH0wP9IAA4qz39+OA2yz8fTMvHDB1a6V\nH18SkBENb6ZllGovu60IUgJCKy2sizGkBGUax9ec2ByAzHL1al3W3g==\n=arDu\n-----END PGP SIGNATURE-----\n"}]}