Correct claim about number of packs per backup

The current sentence implies that there is only one pack file per backup
run, which is not necessarily correct.

Because of the "constants" max_pack_size and max_pack_objects that are
used as limits to pack sizes, we may end up with more than one pack per
backup if there is a lot of data that needs to be stored.

Signed-off-by: Gabriel Filion <gabster@lelutin.ca>
[rlb@defaultvalue.org: adjust commit summary]
Reviewed-by: Rob Browning <rlb@defaultvalue.org>

diff --git a/README.md b/README.md
index f66dd4ebd7e19b4c61744056c7733a5ef9de4b68..fab49049bc5f075f7d0a801aed16856910ddc7cf 100644 (file)
--- a/README.md
+++ b/README.md
@@ -353,8 +353,8 @@ python.
 
 Basically, 'bup split' reads the data on stdin (or from files specified on
 the command line), breaks it into chunks using a rolling checksum (similar to
-rsync), and saves those chunks into a new git packfile.  There is one git
-packfile per backup.
+rsync), and saves those chunks into a new git packfile.  There is at least one
+git packfile per backup.
 
 When deciding whether to write a particular chunk into the new packfile, bup
 first checks all the other packfiles that exist to see if they already have that