Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> 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@xxxxxxxx> > 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@xxxxxxxxxxxxxxx> > To: Git Mailing List <git@xxxxxxxxxxxxxxx> > > 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. - 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