Recent and near future backward incompatibilities

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.