On Wed, Oct 14, 2020 at 12:24:20AM +0200, Tim Düsterhus wrote:
> I assume the following happened:
>
> 1. git started downloading the packfile into a temporary file [0]
> 2. git finished the download (I got all the bytes).
> 3. I killed git before it was able to rename the temporary file.
> 4. When trying again git tries to resume the download [1].
> 5. Because I already got the whole file git will send an invalid range.
> 6. nginx does not like it and sends a 416.
> 7. git hard fails instead of retrying without the 'Range' header and
> without taking the 'content-range' response into account.
>
> So the stuff happening in step (7) would IMO be a git bug.
I wouldn't have thought about such a client-side issue, indeed!
You may be interested in discussing it on the git mailing list:
[email protected]
(not subscription required, just like here).
> I already copied my local repository to test out whether truncating
> works. I could fix the issue by truncating off the last byte, causing
> git to send a valid range:
>
> truncate -s 21680736 pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack.temp
>
> After that worked I did the same on my real repository and called `fsck`
> + `gc` to make sure I did not break anything.
And this validates your theory above. Good job!
> I believe the server side `git gc` would have fixed it as well, because
> the pack file in question is completely gone now. It was replaced by a
> single large pack :-)
Yep indeed!
Time to get some sleep for me now, have a nice night :-)
Willy
