On Tue, Feb 12, 2008 at 11:02:06AM -0500, Nicolas Pitre wrote: > I think this is a good idea to always have some sanity checks on any > incoming objects so to make sure they're well formed and valid before > giving them a SHA1 value, and bail out as soon as any error is found. > From my understanding that's what your patch is doing, right? (sorry I > can't find them in my mailbox anymore). Yes. (=>http://marc.info/?l=git&m=120266631524947&w=2) > This can be done as objects are > coming in just fine and requires no extra memory, and I would say this > should be done unconditionally all the time. After all, the Git > coherency model is based on the SHA1 checksuming, and therefore it is a > good idea to never validate any malformed objects with a SHA1. So I'm > all in favor of such validation always performed in index-pack and > unpack-objects. We will need some additional memory for struct blob/tree/tag/commit even for this check. I'll start reworking my patches. > As to making sure those objects are well connected... well this is a > technically different issue entirely, and I wonder if a special mode to > fsck might not be a better solution. For example, fsck could be made to > validate object connectivity, starting from the new ref(s), and stopping > object walking as soon as a reference to an object not included in the > newly received pack is encountered. This could be run from some hook to > decide whether or not to update the new refs, and to delete the pack > otherwise. Do you really think, that this will need less memory? fsck loads first all objects and then verifies their connections. 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
