git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Unresolved issues #3

From
A Large Angry SCM <gitzilla@gmail.com>
Date
Aug 21, 2006, 04:05 UTC
Message-ID
<44E930FE.3030704@gmail.com>
In-Reply-To
<7vk653xa3a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 52 quoted lines
> 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.

Previous: Junio C HamanoNext: Jeff King
Message 9 of 30 in “Unresolved issues #3”
  1. Junio C HamanoAug 18, 2006
  2. A Large Angry SCMAug 18, 2006
  3. Nicolas PitreAug 18, 2006
  4. A Large Angry SCMAug 18, 2006
  5. Nicolas PitreAug 18, 2006
  6. A Large Angry SCMAug 19, 2006
  7. Nicolas PitreAug 20, 2006
  8. Junio C HamanoAug 20, 2006
  9. A Large Angry SCMAug 21, 2006
  10. Jeff KingAug 18, 2006
  11. Catalin MarinasAug 18, 2006
  12. Junio C HamanoAug 18, 2006
  13. Catalin MarinasAug 18, 2006
  14. Jakub NarebskiAug 18, 2006
  15. Aneesh Kumar K.VAug 18, 2006
  16. Jakub NarebskiAug 18, 2006
  17. Aneesh Kumar K.VAug 18, 2006
  18. Jakub NarebskiAug 18, 2006
  19. Jon LoeligerAug 18, 2006
  20. Junio C HamanoAug 20, 2006
  21. daemon: prepare for multiple services.Junio C Hamano, Aug 21, 2006
  22. daemon: add upload-tar service.Junio C Hamano, Aug 21, 2006
  23. Martin LanghoffAug 23, 2006
  24. Jakub NarebskiAug 25, 2006
  25. Unresolved issues #4Junio C Hamano, Oct 6, 2006
  26. Jakub NarebskiOct 6, 2006
  27. Shawn PearceOct 6, 2006
  28. Jon LoeligerOct 6, 2006
  29. Shawn PearceOct 6, 2006
  30. A Large Angry SCMOct 6, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.