Home Explore Blog CI



git

4th chunk of `Documentation/config/pack.adoc`
2ac7ff65e9c16478783e8f214d297ea267280884d59397db0000000100000c50
 if they exist,
	ignoring them otherwise), and build up a bitmap at the boundary
	instead.
+
When using this algorithm, Git may include too many objects as a result
of not opening up trees belonging to certain UNINTERESTING commits. This
inexactness matches the non-bitmap traversal algorithm.
+
In many cases, this can provide a speed-up over the exact algorithm,
particularly when there is poor bitmap coverage of the negated side of
the query.

pack.useSparse::
	When true, git will default to using the '--sparse' option in
	'git pack-objects' when the '--revs' option is present. This
	algorithm only walks trees that appear in paths that introduce new
	objects. This can have significant performance benefits when
	computing a pack to send a small change. However, it is possible
	that extra objects are added to the pack-file if the included
	commits contain certain types of direct renames. Default is
	`true`.

pack.preferBitmapTips::
	When selecting which commits will receive bitmaps, prefer a
	commit at the tip of any reference that is a suffix of any value
	of this configuration over any other commits in the "selection
	window".
+
Note that setting this configuration to `refs/foo` does not mean that
the commits at the tips of `refs/foo/bar` and `refs/foo/baz` will
necessarily be selected. This is because commits are selected for
bitmaps from within a series of windows of variable length.
+
If a commit at the tip of any reference which is a suffix of any value
of this configuration is seen in a window, it is immediately given
preference over any other commit in that window.

pack.writeBitmaps (deprecated)::
	This is a deprecated synonym for `repack.writeBitmaps`.

pack.writeBitmapHashCache::
	When true, git will include a "hash cache" section in the bitmap
	index (if one is written). This cache can be used to feed git's
	delta heuristics, potentially leading to better deltas between
	bitmapped and non-bitmapped objects (e.g., when serving a fetch
	between an older, bitmapped pack and objects that have been
	pushed since the last gc). The downside is that it consumes 4
	bytes per object of disk space. Defaults to true.
+
When writing a multi-pack reachability bitmap, no new namehashes are
computed; instead, any namehashes stored in an existing bitmap are
permuted into their appropriate location when writing a new bitmap.

pack.writeBitmapLookupTable::
	When true, Git will include a "lookup table" section in the
	bitmap index (if one is written). This table is used to defer
	loading individual bitmaps as late as possible. This can be
	beneficial in repositories that have relatively large bitmap
	indexes. Defaults to false.

pack.readReverseIndex::
	When true, git will read any .rev file(s) that may be available
	(see: linkgit:gitformat-pack[5]). When false, the reverse index
	will be generated from scratch and stored in memory. Defaults to
	true.

pack.writeReverseIndex::
	When true, git will write a corresponding .rev file (see:
	linkgit:gitformat-pack[5])
	for each new packfile that it writes in all places except for
	linkgit:git-fast-import[1] and in the bulk checkin mechanism.
	Defaults to true.

Title: Advanced Git Packing Configuration Options
Summary
This section describes various Git configuration options related to packing, including sparse packing, bitmap preferences, cache settings, lookup tables, and reverse index management, which can impact performance, disk space, and pack file composition.