In previous commits in this PR we introduced a new utility command
for our test suite, lfstest-genrandom, which reliably produces
random data on all the platforms we support (in several forms of
base64 encoding or as raw binary data), and then converted much of
our test suite to make use of this new command.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the "uuidgen" command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the blobs actually have empty
data in this case.  The test still passes because it doesn't depend
on the length of the random data, and the error exit code from the
missing "uuidgen" command is ignored.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom command instead of the
"uuidgen" command.  We use the --base64 flag and a slightly larger size
for the output base64-encoded string than the length of a UUID.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces
random data on all the platforms we support (in several forms of
base64 encoding or as raw binary data), and then converted much of
our test suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the "uuidgen" command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the blobs actually have empty
data in this case.  The test still passes because it doesn't depend
on the length of the random data, and the error exit code from the
missing "uuidgen" command is ignored.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
"uuidgen" command.  We use the --base64 flag and a slightly larger size
for the output base64-encoded string than the length of a UUID.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces
random data on all the platforms we support (in several forms of
base64 encoding or as raw binary data), and then converted much of
our test suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the "uuidgen" command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the blobs actually have empty
data in this case.  The test still passes because it doesn't depend
on the length of the random data, and the error exit code from the
missing "uuidgen" command is ignored.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
"uuidgen" command.  We use the --base64 flag and a slightly larger size
for the output base64-encoded string than the length of a UUID.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces
random data on all the platforms we support (in several forms of
base64 encoding or as raw binary data), and then converted much of
our test suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the "uuidgen" command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the blobs actually have empty
data in this case.  The test still passes because it doesn't depend
on the length of the random data, and the error exit code from the
missing "uuidgen" command is ignored.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
"uuidgen" command.  We use the --base64 flag and a slightly larger size
for the output base64-encoded string than the length of a UUID.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces random
data on all the platforms we support (in several forms of Base64
encoding, or as raw binary data), and then converted much of our test
suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the uuidgen(1) command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the objects actually have empty
data on that platform.  The test still passes because it doesn't depend
on the length of the random data, and because the non-zero exit code
caused by the missing uuidgen(1) command is ignored as it appears earlier
in a pipeline whose final command (our lfstest-testutils program)
always succeeds.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
uuidgen(1) command.  We pass the --base64 flag to our program and request
a slightly larger size for the output Base64-encoded string than the
length of a UUID, just to ensure we are using a similar amount of random
data as before, although this doesn't actually affect the success or
failure of the test.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces random
data on all the platforms we support (in several forms of Base64
encoding, or as raw binary data), and then converted much of our test
suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the uuidgen(1) command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the objects actually have empty
data on that platform.  The test still passes because it doesn't depend
on the length of the random data, and because the non-zero exit code
caused by the missing uuidgen(1) command is ignored as it appears earlier
in a pipeline whose final command (our lfstest-testutils program)
always succeeds.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
uuidgen(1) command.  We pass the --base64 flag to our program and request
a slightly larger size for the output Base64-encoded string than the
length of a UUID, just to ensure we are using a similar amount of random
data as before, although this doesn't actually affect the success or
failure of the test.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces random
data on all the platforms we support (in several forms of Base64
encoding, or as raw binary data), and then converted much of our test
suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the uuidgen(1) command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the objects actually have empty
data on that platform.  The test still passes because it doesn't depend
on the length of the random data, and because the non-zero exit code
caused by the missing uuidgen(1) command is ignored as it appears earlier
in a pipeline whose final command (our lfstest-testutils program)
always succeeds.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
uuidgen(1) command.  We pass the --base64 flag to our program and request
a slightly larger size for the output Base64-encoded string than the
length of a UUID, just to ensure we are using a similar amount of random
data as before, although this doesn't actually affect the success or
failure of the test.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)