Size_t : Make large files work

[PhilipOakley]

SUCCESS. It's still rough, but it's working.

Just wanted to get it out there.

This is on top of shears/pu and t-b's big size_t patch.

Signed-off-by: Philip Oakley [email protected]

phili@Philip-Win10 MINGW64 /usr/src/git/t (size_t5)
$ ./t-large-files-on-windows.sh -i -v -x -d
Initialized empty Git repository in C:/git-sdk-64/usr/src/git/t/trash directory.t-large-files-on-windows/.git/
checking prerequisite: SIZE_T_IS_64BIT

mkdir -p "$TRASH_DIRECTORY/prereq-test-dir" &&
(
        cd "$TRASH_DIRECTORY/prereq-test-dir" &&
        test 8 -le "$(build_option sizeof-size_t)"

)
++ mkdir -p '/usr/src/git/t/trash directory.t-large-files-on-windows/prereq-test-dir'
++ cd '/usr/src/git/t/trash directory.t-large-files-on-windows/prereq-test-dir'
+++ build_option sizeof-size_t
+++ git version --build-options
+++ sed -ne 's/^sizeof-size_t: //p'
++ test 8 -le 8
prerequisite SIZE_T_IS_64BIT ok
expecting success:

        test-tool zlib-compile-flags >zlibFlags.txt &&
        dd if=/dev/zero of=file bs=1M count=4100 &&
        git config core.compression 0 &&
        git config core.looseCompression 0 &&
        git add file &&
        git verify-pack -s .git/objects/pack/*.pack &&
        git fsck --verbose --strict --full &&
        git commit -m msg file &&
        git log --stat &&
        git gc &&
        git fsck --verbose --strict --full &&
        git index-pack -v -o test.idx .git/objects/pack/*.pack &&
        git gc &&
        git fsck

++ test-tool zlib-compile-flags
++ dd if=/dev/zero of=file bs=1M count=4100
4100+0 records in
4100+0 records out
4299161600 bytes (4.3 GB, 4.0 GiB) copied, 6.89465 s, 624 MB/s
++ git config core.compression 0
++ git config core.looseCompression 0
++ git add file
++ git verify-pack -s .git/objects/pack/pack-88fec382e989b72b87fdd0ecc88bb70529b3dd0b.pack
non delta: 1 object
++ git fsck --verbose --strict --full
Checking object directory
Checking blob 754a93d6fada4c6873360e6cb4b209132271ab0e
Checking HEAD link
notice: HEAD points to an unborn branch (master)
notice: No default references
Checking connectivity (32 objects)
Checking 754a93d6fada4c6873360e6cb4b209132271ab0e
++ git commit -m msg file
[master (root-commit) 1114911] msg
 Author: A U Thor <[email protected]>
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file
++ git log --stat
commit 11149116b3df24b582e545deb18b16fe1492a65d (HEAD -> master)
Author: A U Thor <[email protected]>
Date:   Mon Apr 22 22:39:33 2019 +0000

    msg

 file | Bin 0 -> 4194304 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
++ git gc
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 1 (delta 0)
++ git fsck --verbose --strict --full
Checking object directory
Checking commit 11149116b3df24b582e545deb18b16fe1492a65d
Checking blob 754a93d6fada4c6873360e6cb4b209132271ab0e
Checking tree 1a9c7e21bb658a2600dc0c191b7efb654106f754
Checking HEAD link
Checking reflog 0000000000000000000000000000000000000000->11149116b3df24b582e545deb18b16fe1492a65d
Checking reflog 0000000000000000000000000000000000000000->11149116b3df24b582e545deb18b16fe1492a65d
Checking cache tree
Checking connectivity (32 objects)
Checking 11149116b3df24b582e545deb18b16fe1492a65d
Checking 754a93d6fada4c6873360e6cb4b209132271ab0e
Checking 1a9c7e21bb658a2600dc0c191b7efb654106f754
++ git index-pack -v -o test.idx .git/objects/pack/pack-6c993b46fa70cbd847fa02eb7b618f6cbb576b2d.pack
Indexing objects: 100% (3/3), done.
6c993b46fa70cbd847fa02eb7b618f6cbb576b2d
++ git gc
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 3 (delta 0)
++ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (3/3), done.
ok 1 - require 64bit size_t

# passed all 1 test(s)
1..1

phili@Philip-Win10 MINGW64 /usr/src/git/t (size_t5)
$

[tboegi]

That's good news.
Should we use git-for-windows as the base-line ?

[dscho]

@PhilipOakley maybe we'll close this PR in favor of #2179?

[PhilipOakley]

Yes. Let's consolidate on #2179.