On Tue, Feb 26, 2008 at 01:19:51AM -0800, Junio C Hamano wrote: > Is this series an unadjusted resend or something? This particular one > had funny interaction with your own d4fe07f (git-fsck: report missing > author/commit line in a commit as an error) that is already in > 'master', so I had to munge it by hand. I sent the series directly based on master, as Shawn suggested (21c34 is only changing the prefix in Makefile): 3c5fb6a798a0b686e7818bf1da63791fb94a7b21 receive-pack: use strict mode for unpacking objects 786bf704ce4067c80055a1fa69be242a59880eb0 index-pack: introduce checking mode 1f7ae754550fb6e0509c1498ba9de6b5f4bba438 unpack-objects: prevent writing of inconsistent objects 143aa20e11c70595e4119a3adac0887446524c7f unpack-object: cache for non written objects 997a515fccb3ef200cb96fbb757366eff8a2ee66 add common fsck error printing function b0785b6b99c641b2fec99eb48da340af627e3b0d builtin-fsck: move common object checking code to fsck.c fa9c45a16cc194c87c113c9740eb5a6e17b66cc1 builtin-fsck: reports missing parent commits a93e35027c53f06d2db2adbb14fa916871e23e46 Remove unused object-ref code 19eae91b8e3d2e72616397edf77a13d4ac79d7ab builtin-fsck: move away from object-refs to fsck_walk 0ca75709265281548be81cad4f396f4cf936dbfb add generic, type aware object chain walker 21c34821c02458f45422e747853bde913d43c625 Lokale Anpassung Makefile 99d8ea2c5ce6fc0b06fe8a43e7c0c108ddad853b git-bundle.txt: Add different strategies to create the bundle 8e0fbe671f6a63b885702917bf4e7d7a85c59ab4 builtin-for-each-ref.c: fix typo in error message 8a8bf4690e20a545561249a9b393c1ef3239c03d send-email: test compose functionality The patch was sent as usual, so I don't know, why it should not apply. > It was not so pleasant > (a large chunk of code was moved from builtin-fsck.c to fsck.c), > but that is what the maintainer does, so it's Ok. But I'd like > you to eyeball the result to see if it looks sane. I have compared it to 3c5fb6a798a0b686e7818bf1da63791fb94a7b21 and everything seems to look OK. I'll do better verification in the next days. > I'll push it out as part of 'pu'. The tip of your topic is > 154a955 (receive-pack: use strict mode for unpacking objects) > tonight: > > Side note: To find a tip of a topic yourself, look for "Merge > mk/maint-parse-careful" in "git log --first-parent > origin/next..origin/pu" output and find the latest one. > One thing I noticed was that parse_$type_buffer() family all take > non-const void *buf pointers but one new caller you introduced takes > "const void *data" and passes that pointer to them. I hated to, but > ended up loose-casting it. You may want to make the function take > non-const pointer, but I did not look very carefully. The easiest thing would be to remove the const from the data parameter in sha1_object (index-pack.c). How should I handle changes? Send a patch ontop of 154a955 or should I send a amended version of the patches? > By the way, while I was at it, many stylistic issues bugged me too > much, so I ended up fixing them as well: > [...] > > * If you cast, cast to the right type ;-) > > struct tree *item = (struct tree *) obj; > > not > > struct tree *item = (struct item*) obj; > > Please do not make me do this again, as I do not have infinite amount > of time. This plea is not only about your patch but applies to > everybody. Sorry for struct item. I really should have looked more carefully at the make output. I did not know all of these styling guidelines. SubmittingPatches only talks about broken mailer. Maybe it would be a good thing to include them somewhere. As I'm not very good at catching all these issues, I tried checkpatch.pl (from the linux.git:/scripts) on my patches. After turning the 80 characters/line check off, it show me formating errors, about which you complained. So I'll try to run it over my patches in the future. mfg Martin Kögler - 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
