summaryrefslogtreecommitdiff
path: root/Documentation/howto
diff options
context:
space:
mode:
authorThomas Ackermann <th.acker@arcor.de>2014-11-03 20:37:07 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-11-04 21:14:44 (GMT)
commitf745acb028ee8f7dcd1c8f10127b8feeaa255cf7 (patch)
tree664ed49a136f9e91d8e0cd58ef01576876ad10c0 /Documentation/howto
parentdd83521629d95d0c8e4aff85edb16715a13689a3 (diff)
downloadgit-f745acb028ee8f7dcd1c8f10127b8feeaa255cf7.zip
git-f745acb028ee8f7dcd1c8f10127b8feeaa255cf7.tar.gz
git-f745acb028ee8f7dcd1c8f10127b8feeaa255cf7.tar.bz2
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 <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/howto')
-rw-r--r--Documentation/howto/recover-corrupted-object-harder.txt4
1 files changed, 2 insertions, 2 deletions
diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt
index 6f33dac..23e685d 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