Re: Recent and near future backward incompatibilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas Pitre <nico@xxxxxxx> writes:

> Actually it doesn't have to be that expensive to convert deltas v2 to 
> deltas v3 on the fly.  They can be inflated, parsed, the copy ops that 
> exceed 0x10000 converted into multiple ops of smaller copy blocks, then 
> deflated.  This is certainly much less costly than rematching deltas 
> from scratch.

True, when I think about it.

>>  - we need to add .git/config item that tells pack-objects to
>>    never generate version 3 delta for that particular
>>    repository.  This is similar to the way we would need to
>>    control the use of delta-base-offset representation currently
>>    cooking in "next".
>
> This is different. The delta-base-offset representation is decided at 
> run time every time a pack is generated and regardless if delta data is 
> being reused from another pack or regenerated afresh, and so with no 
> cost.  So this is no issue for users of old GIT versions since the 
> native GIT protocol already handle it in a backward compatible manner.
>
> The only issue here concerns users that don't use the native GIT 
> protocol.  But in this case they have two options: either they switch to 
> the native protocol, or they upgrade to the latest GIT version which 
> can always be pulled with the native GIT protocol.

True again.  Thanks.


-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]