Recent and near future backward incompatibilities

[Junio C Hamano <junkio@cox.net>]

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.