It was brought to my attention that the public git.git repository cannot be cloned with older versions of git. More precisely, packs generated with post 16854571 (NOT contained in v1.4.2.3 but in the current "master" and more importantly in v1.4.3-rc3 which I tagged tonight) can contain deltas that are not compatible with the version of git before d60fc1c8, which means that v1.1.6 and older (v1.2.0 and later are Ok). The older version of git did not know anything about version 3 delta (which can express larger copies from source when computing a delta) before d60fc1c8, and barfs if it is fed a pack that contains such a delta. We have generated only version 2 delta for quite a while until very recently post v1.4.2.3. The thing is, I made a mistake to repack my public repository with more recent git (I work with "next" usually, and with "master" after we go into -rcX cycle to prepare for the release). Although the version of git that kernel.org runs is still v1.4.2.3 which means its pack-objects does not produce version 3 delta by itself, the problem is that the delta reuse logic happily copies out whatever delta is in existing packs. I already repacked the public repository with an older git, v1.4.2.3, using 'git-repack -a -d -f' to fix this problem. One thing we can and should immediately do is to revert 16854571 for now until we decide how to resolve this issue cleanly. These are what needs to happen but one of them is quite tricky: - the reusing of delta is what makes pack-objects practical, and it is expensive to look into existing delta to see if it is version 2 or version 3 before deciding to reuse each delta data, so even if we update pack-objects so that we can tell it to generate a pack that contains only version 2 deltas, it would be very expensive to do so and may not be practical. I am not sure how to resolve this issue efficiently right now; we need a bit of thinking. - so instead we could just say a public repository that needs to interoperate with older clients should not keep packs with version 3 delta, at least for now. deltifying from loose objects are done afresh every time pack-objects is run, and it is easier to control. - git-pack-objects needs to be updated so that we can control whether we generate version 2 or version 3 delta. - we need to add .git/config item that tells pack-objects to never generate version 3 delta for that particular repository. This is similar to the way we would need to control the use of delta-base-offset representation currently cooking in "next". - the on-the-wire protocol between fetch-pack and upload-pack needs to be updated so that the server side can tell if the client side is prepared to handle version 3 delta in the pack, and this needs to be passed to pack-objects to control its operation. This part I can see how to fix. We may have a similar issue when enabling generation of loose objects with new style headers. This is already controlled with the core.legacyheaders configuration item. - 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