Re: Unresolved issues #3

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

Nicolas Pitre wrote:
> On Fri, 18 Aug 2006, A Large Angry SCM wrote:
> 
>> Nicolas Pitre wrote:
>>> On Thu, 17 Aug 2006, A Large Angry SCM wrote:
>> ...
>>>> 1) I disagree with Nico's assessment that, other than his, there can not
>>>> exist any type 2 packs that have bit 6 set to mean copy from result.
>>> Care to explain why?
>>>
>>> Since this code is mine I can tell you that no official GIT version ever 
>>                                               ^^^^^^^^^^^^^^^^^^^^^^^
>>> produced such a pack.  The code to make use of that bit was quite 
>>> involving and the end result wasn't great at all so I never published 
>>> said code.  This is also why current GIT accepts both pack version 2 and 
>>> 3 without any distinction using the same code in patch-delta.c on the 
>>> basis that no version 2 packs ever used that bit.
>> That doesn't prove the non-existence of other code to do it.
> 
> So?  If the official and primary code for GIT doesn't support it, what 
> is the point?  I'm telling you that if such packs exist they will simply 
> barf with all official GIT releases later than v1.1.6 making your 
> argument pointless.
> 
> I don't mind you documenting that historic intent for a bit that was 
> never officially used, but at least let's document it right.

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.

Since there was not any documentation that declared the bit as reserved,
the code was the documentation and it specified that bit 6 of the first
byte of a delta hunk was to be interpreted as meaning the the copy
source in the result buffer. The code did not and does not document intent.