On Tue, Jun 10, 2008 at 10:44:43AM -0700, Linus Torvalds wrote:
> You can fix this multiple ways. One would be to pick another size that is
> simply less likely (eg ~0 instead), which leaves the theoretical race, and
> just makes it practically impossible to hit (not that I think it's very
> practical to hit already).
Hmm. I may have just hit it in the test suite.
Try this:
cd git/t
for i in `seq 1 1000`; do
./t4126-apply-empty.sh -v -i || break
done
echo made it to $i
Most of the time it works, but somewhere in that thousand (generally
within a few hundred), I end up with a failed test. The failure looks
like:
* expecting success:
git reset --hard &&
>empty &&
rm -f missing &&
git apply --index patch0 &&
test_cmp expect empty &&
git diff --exit-code
HEAD is now at e3f79fd initial
error: empty: does not match index
* FAIL 3: apply --index empty
> The other approach is to know that an empty blob always has a very
> specific SHA1. Here's an trial patch.
However, I can still trigger the failure with your patch, so I wonder if
it is some other race entirely...
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
