On Sun, Feb 14, 2010 at 01:09:23AM +0300, Dmitry Potapov wrote: > On Sat, Feb 13, 2010 at 7:29 PM, Ilari Liusvaara > <ilari.liusvaara@xxxxxxxxxxx> wrote: > > Hmm... One needs to copy the data block at time into temporary buffer > > and use that for feeding zlib and SHA-1. That ensures that whatever > > SHA-1 hashes and zlib compresses are consistent. > > If you want this then just compile Git with NO_MMAP = YesPlease > It should solve the described problem. Doesn't that also turn off mmap in other places where it's harmless or even beneficial? Otherwise, why use mmap in Git at all? It also doesn't solve the problem in cases when mmap support is compiled in. There is a performance-robustness trade-off here. If we do an extra copy of the file data, we get always consistent repo contents but lose speed (not very much speed, since sha1 and zlib are much slower than a memory copy). If we don't, we still get consistent repo contents if--and only if--the files never happen to be modified during a git add. I can live with that, as long as the limitation is documented and there's a config switch somewhere that I can turn on for cases when I can't make such assurances. I imagine similar reasoning led to the existence of the receive.fsckObjects option. Personally, checking all objects fetched from remote repos is not a feature I'd ever want to be able to turn off; however, it's easy to think of cases where integrity matters less than speed (e.g. build systems doing clone-build-destroy cycles from a trusted, reliable server over a similarly trusted network). -- 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