On Fri, 22 Jun 2007, Shawn O. Pearce wrote: > Yes, however my point here is that I think we have historically > been bad about making our software reasonably future-proof. > > The .pack file has a version field, with value 2. REF_DELTA is not > supported by those binaries that predated its introduction. They are > unable to properly unpack, index or read a packfile using REF_DELTA. > Why did the .pack version stay at 2 if REF_DELTA is used in the file? Because: 1) you wouldn't be able to properly unpack, index or read a pack file using those deltas even with a different pack version _anyway_, and 2) the pack encoding itself has not changed at all. And #2 is real. The introduction of an additional object type didn't turn the pack content into something that old git versions could (mis)interpret and be fooled by. On the other hand, changes leading to pack version 3 really required a pack version bump as those changes could really be misinterpreted by older git versions. The fact that old git versions call the pack corrupt when it contains unknown objects is a problem with the error message not the pack version. We even had a bad error message for unknown pack versions too before you improved it. Nicolas - 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
