Duy Nguyen <pclo...@gmail.com> writes: > This "size" field contains the delta size if the in-pack object is a > delta. So blindly falling back to object_sha1_info() which returns the > canonical object size is definitely wrong.
Yup. Also we need to be careful when going back to the packfile to read the size in question. A different packfile that has the same object may have delta that was constructed differently and of wrong size. > Please eject the series > from 'pu' until I fix this. The bug won't likely affect anyone (since > they must have 4GB+ objects to trigger it) but better safe than sorry. > BTW can you apply this patch? This broken && chain made me think the > problem was in the next test. It would have saved me lots of time if I > saw this "BUG" line coming from the previous test. Thanks, will do. > > -- 8< -- > Subject: [PATCH] t9300: fix broken && chain > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com> > --- > t/t9300-fast-import.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh > index e4d06accc4..e2a0ae4075 100755 > --- a/t/t9300-fast-import.sh > +++ b/t/t9300-fast-import.sh > @@ -348,7 +348,7 @@ test_expect_success 'B: accept branch name "TEMP_TAG"' ' > INPUT_END > > test_when_finished "rm -f .git/TEMP_TAG > - git gc > + git gc && > git prune" && > git fast-import <input && > test -f .git/TEMP_TAG && > @@ -365,7 +365,7 @@ test_expect_success 'B: accept empty committer' ' > INPUT_END > > test_when_finished "git update-ref -d refs/heads/empty-committer-1 > - git gc > + git gc && > git prune" && > git fast-import <input && > out=$(git fsck) &&
