SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
>> +diff --git a/file0 b/file0
>> +new file mode 100644
>> +index 0000000000000000000000000000000000000000..01e79c32a8c99c557f0757da7cb6d65b3414466d
>> +--- /dev/null
>> ++++ b/file0
>> +@@ -0,0 +1,3 @@
>> ++1
>> ++2
>> ++3
>> +diff --git a/file2 b/file2
>> +new file mode 100644
>> +index 0000000000000000000000000000000000000000..01e79c32a8c99c557f0757da7cb6d65b3414466d
>> +--- /dev/null
>> ++++ b/file2
>> +@@ -0,0 +1,3 @@
>> ++1
>> ++2
>> ++3
>> +$
>
> All these new tests break when run with GIT_TEST_DEFAULT_HASH=sha256
> with something like:
>
> + test_cmp expect actual
> --- expect 2020-08-14 15:05:12.209285397 +0000
> +++ actual 2020-08-14 15:05:12.205285279 +0000
> @@ -2,7 +2,7 @@
> 0000000000000000000000000000000000000000000000000000000000000000
> diff --git a/dir/sub b/dir/sub
> new file mode ffff44
> -index ffffffffff..fffffffa79
> +index ffffffffff..fffffff895
Ouch. These apparently come from
process_diffs () {
_x04="[0-9a-f][0-9a-f][0-9a-f][0-9a-f]" &&
_x07="$_x05[0-9a-f][0-9a-f]" &&
sed -e "s/$OID_REGEX/$ZERO_OID/g" \
-e "s/From $_x40 /From $ZERO_OID /" \
-e "s/from $_x40)/from $ZERO_OID)/" \
-e "s/commit $_x40\$/commit $ZERO_OID/" \
-e "s/commit $_x40 (/commit $ZERO_OID (/" \
-e "s/$_x40 $_x40 $_x40/$ZERO_OID $ZERO_OID $ZERO_OID/" \
-e "s/$_x40 $_x40 /$ZERO_OID $ZERO_OID /" \
-e "s/^$_x40 $_x40$/$ZERO_OID $ZERO_OID/" \
-e "s/^$_x40 /$ZERO_OID /" \
-e "s/^$_x40$/$ZERO_OID/" \
-e "s/$_x07\.\.$_x07/fffffff..fffffff/g" \
-e "s/$_x07,$_x07\.\.$_x07/fffffff,fffffff..fffffff/g" \
-e "s/$_x07 $_x07 $_x07/fffffff fffffff fffffff/g" \
-e "s/$_x07 $_x07 /fffffff fffffff /g" \
-e "s/Merge: $_x07 $_x07/Merge: fffffff fffffff/g" \
-e "s/$_x07\.\.\./fffffff.../g" \
-e "s/ $_x04\.\.\./ ffff.../g" \
-e "s/ $_x04/ ffff/g" \
"$1"
}
Hash-independence may be good, but it should not munge expected mode
bits from 100644 to ffff44, which I think is a bug in the original
introduced in 72f936b1 (t4013: make test hash independent,
2020-02-07).
When we are adjusting the abbrev length of the index line, of course
$_x07 would not be sufficient to match the abbreviated object name
in full, so a79 vs 895 can be explained and is a bug in this patch
that did not update the process_diffs helper.
Another thing that I find somewhat problematic in the original
(brian cc'ed) is that it does not special case all-zero object name
specially. By turning any and all instances of $_x40 to $ZERO_OID,
we lose the distinction between a random-looking object name which
got turned into $ZERO_OID by the processing, and an object name that
was $ZERO_OID from the beginning, so we won't catch a possible
future bug where new file's preimage object name is not $ZERO_OID
(this is plausible when you try to show an intent-to-add entry; the
diff between the index and the working tree would be "new file"
patch, but the index entry records the object name for an empty
blob, e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 instead of $ZERO_OID
can easily be emitted by a mistaken implementation).
