Commit Briefs
fix seek to incorrect offset in the delta base when creating deltas
The stretchblk() function needs to compare data located after the block which has just been matched. However, upon entry it was resetting the file pointer of the delta base to the beginning(!) of the block. The other file is correctly positioned after the block. In many cases the data won't match and stretchblk() will not stretch the matched block. But when the data did happen to match this resulted in a bogus delta, and wrong file contents when the delta was applied. Fix this by setting the delta base file pointer to end of the block. Problem reported by naddy after our server refused a pack file which was sent by 'got send'. I could reproduce the issue by running the 'gotadmin pack' command on a copy of naddy's repository. ok naddy
allow the delta base file to lose its header between deltify_init and deltify
This simplifies pack file creation. A delta base could be read from a loose object, a packfile, or it might be available in a temporary file. All these cases can now be handled the same way. We may need to open, close, and re-open a given delta base multiple times while packing.
in addblk(), only read data into buffer1 if we will compare it to buffer2
suggested by and ok naddy@
check a block's hash as well as its length before expensive comparisons
suggested by + ok naddy, and Ori agrees
fix off-by-one error in delta length; from ori
git9 commit fbb2fb7c87d8edf58e22c84f575853dc9de79ac4