From f745acb028ee8f7dcd1c8f10127b8feeaa255cf7 Mon Sep 17 00:00:00 2001 From: Thomas Ackermann Date: Mon, 3 Nov 2014 21:37:07 +0100 Subject: Documentation: typofixes In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano --- Documentation/howto/recover-corrupted-object-harder.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/howto') diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt index 6f33dac0e0..23e685d8ca 100644 --- a/Documentation/howto/recover-corrupted-object-harder.txt +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -38,7 +38,7 @@ zlib were failing). Reading the zlib source code, I found that "incorrect data check" means that the adler-32 checksum at the end of the zlib data did not match the inflated data. So stepping the data through zlib would not help, as it -did not fail until the very end, when we realize the crc does not match. +did not fail until the very end, when we realize the CRC does not match. The problematic bytes could be anywhere in the object data. The first thing I did was pull the broken data out of the packfile. I @@ -195,7 +195,7 @@ halfway through: ------- I let it run to completion, and got a few more hits at the end (where it -was munging the crc to match our broken data). So there was a good +was munging the CRC to match our broken data). So there was a good chance this middle hit was the source of the problem. I confirmed by tweaking the byte in a hex editor, zlib inflating the -- cgit v1.2.1