--- OLD/Documentation/git-fast-import.txt	Thu Jan  1 00:00:00 1970
+++ NEW/Documentation/git-fast-import.txt	Thu Jan  1 00:00:00 1970
@@ -44,8 +44,8 @@
 	not contain the old commit).
 
 --max-pack-size=<n>::
-	Maximum size of each output packfile, expressed in MiB.
-	The default is 4096 (4 GiB) as that is the maximum allowed
+	Maximum size of each output packfile, expressed in MB.
+	The default is 4096 (4 GB) as that is the maximum allowed
 	packfile size (due to file format limitations). Some
 	importers may wish to lower this, such as to ensure the
 	resulting packfiles fit on CDs.
@@ -80,7 +80,7 @@
 	<file> listing the filename of the packfile and the last
 	commit on each branch that was written to that packfile.
 	This information may be useful after importing projects
-	whose total object set exceeds the 4 GiB packfile limit,
+	whose total object set exceeds the 4 GB packfile limit,
 	as these commits can be used as edge points during calls
 	to 'git-pack-objects'.
 
@@ -591,7 +591,7 @@
 commands to set the correct content will produce the same results
 as sending only the needed `filemodify` and `filedelete` commands.
 The `filedeleteall` approach may however require fast-import to use slightly
-more memory per active branch (less than 1 MiB for even most large
+more memory per active branch (less than 1 MB for even most large
 projects); so frontends that can easily obtain only the affected
 paths for a commit are encouraged to do so.
 
@@ -771,7 +771,7 @@
 ....
 
 Note that fast-import automatically switches packfiles when the current
-packfile reaches \--max-pack-size, or 4 GiB, whichever limit is
+packfile reaches \--max-pack-size, or 4 GB, whichever limit is
 smaller.  During an automatic packfile switch fast-import does not update
 the branch refs, tags or marks.
 
@@ -782,7 +782,7 @@
 
 Frontends may choose to issue checkpoints during extremely large
 and long running imports, or when they need to allow another Git
-process access to a branch.  However given that a 30 GiB Subversion
+process access to a branch.  However given that a 30 GB Subversion
 repository can be loaded into Git through fast-import in about 3 hours,
 explicit checkpointing may not be necessary.
 
@@ -1048,7 +1048,7 @@
 on a 64 bit system the structure is 40 bytes (due to the larger
 pointer sizes).  Objects in the table are not deallocated until
 fast-import terminates.  Importing 2 million objects on a 32 bit system
-will require approximately 64 MiB of memory.
+will require approximately 64 MB of memory.
 
 The object table is actually a hashtable keyed on the object name
 (the unique SHA-1).  This storage configuration allows fast-import to reuse
@@ -1072,7 +1072,7 @@
 Inactive branches are stored in a structure which uses 96 or 120
 bytes (32 bit or 64 bit systems, respectively), plus the length of
 the branch name (typically under 200 bytes), per branch.  fast-import will
-easily handle as many as 10,000 inactive branches in under 2 MiB
+easily handle as many as 10,000 inactive branches in under 2 MB
 of memory.
 
 Active branches have the same overhead as inactive branches, but
@@ -1109,7 +1109,7 @@
 The active branch LRU, when coupled with the filename string pool
 and lazy loading of subtrees, allows fast-import to efficiently import
 projects with 2,000+ branches and 45,114+ files in a very limited
-memory footprint (less than 2.7 MiB per active branch).
+memory footprint (less than 2.7 MB per active branch).
 
 
 Author