Thread (1 message) 1 message, 1 author, 2016-06-15

Re: Recent and near future backward incompatibilities

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:43

Nicolas Pitre [off-list ref] 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.
quoted
 - 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help