Re: Unresolved issues #3

[A Large Angry SCM <gitzilla@gmail.com>]

Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> 
>> On Fri, 18 Aug 2006, A Large Angry SCM wrote:
>>
>>> Historic fact. Between Thu May 19 08:56:22 2005 and Thu Feb  9 21:06:38
>>> 2006 bit 6 of the first byte of a delta hunk was interpreted to mean
>>> that the source of the copy was the result buffer. From Thu May 19
>>> 08:56:22 2005 on, the code to decode delta hunks in type 2 packs was
>>> available to everyone and anyone interested could make a pack encoder
>>> that would create packs that the core Git code would correctly read. The
>>> commit of Thu Feb  9 21:06:38 2006, d60fc, actually introduced a bug
>>> that would treat valid type 2 packs as invalid.
> 
> It is more like the said commit made the pack format extensible
> by declaring the bit reserved for the future use, by declaring
> retroactively that a type 2 pack that used that bit invalid.
> And it was deemed a reasonable and safe decision because no
> official git ever produced a type 2 pack that used that bit,
> 
> Yes, that was a backward incompatible change, strictly speaking,
> and probably I should have made an announcement that looked
> similar to this by Linus:
> 
>         From: Linus Torvalds <torvalds@osdl.org>
>         Subject: CAREFUL! No more delta object support!
>         Date: Mon, 27 Jun 2005 18:14:40 -0700 (PDT)
>         Message-ID: <Pine.LNX.4.58.0506271755140.19755@ppc970.osdl.org>
>         To: Git Mailing List <git@vger.kernel.org>
> 
> So you could argue I was incompetent not to make a big fuss
> about this backward incompatibility back then, if you like.
> 
> I did not think it was worth it back then, and I do not think it
> is worth it now, either.  But if it makes you feel better, I
> could retroactively make such an announcement about the
> unofficial bit 6.
> 
> The announcement would have read like this:
> 
>     The current git code does not support type #2 packs that
>     uses delta with bit 6 to mean "copy inside destination
>     buffer".  Although the code that interpreted delta data
>     supported bit 6 that way for a brief period of time, no
>     official git ever released produced delta that used the
>     bit that way.
> 
>     In other words, if you have created packs with your own,
>     modified git, that took advantage of "copy inside
>     destination buffer" feature in the delta interpretation
>     code, such packs are not usable by the official git, so
>     you need to unpack them using your own version of git
>     and then repack with the official version of git.

Please read the commit message for commit d60fc. It's type _3_ pack
files that redefined bit 6 to add the extra byte of copy length, not
type 2. Thus, no need to retroactively invalidate the type 2 pack files
that used copy from result.