doc/git-repack: small fixes for geometric repacks

Hi,

this small series addresses two issues in our documentation for the git-repack(1) command that relate to geometric repacks.

Patrick

Patrick Steinhardt (2):
doc/git-repack: fix syntax for -g shorthand option doc/git-repack: don't mention nonexistent "--unpacked" option

 Documentation/git-repack.txt | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

2.42.0

The -g switch is a shorthand for --geometric= and allows the user to specify the geometric. The documentation is wrong though and indicates that the syntax for the shorthand is -g=<factor>. In fact though, the option must be specified without the equals sign via -g<factor>.

Fix the syntax accordingly.

---
 Documentation/git-repack.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 8545a32667..dfd2a59c50 100644
@@ -209,7 +209,7 @@ depth is 4095.
 	Pass the `--delta-islands` option to `git-pack-objects`, see
 	linkgit:git-pack-objects[1].
 
--g=<factor>::
+-g<factor>::
 --geometric=<factor>::
 	Arrange resulting pack structure so that each successive pack
 	contains at least `<factor>` times the number of objects as the

2.42.0

The documentation for geometric repacking mentions a "--unpacked" option that supposedly changes how loose objects are rolled up. This option has never existed, and the implied behaviour, namely to include all unpacked objects into the resulting packfile, is in fact the default behaviour.

Correct the documentation to not mention this option.

---
 Documentation/git-repack.txt | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

index dfd2a59c50..d61078b697 100644
@@ -226,11 +226,8 @@ uniquely by the set of packs being "rolled-up"; in other words, the
 packs determined to need to be combined in order to restore a geometric
 progression.
 +
-When `--unpacked` is specified, loose objects are implicitly included in
-this "roll-up", without respect to their reachability. This is subject
-to change in the future. This option (implying a drastically different
-repack mode) is not guaranteed to work with all other combinations of
-option to `git repack`.
+Loose objects are implicitly included in this "roll-up", without respect to
+their reachability. This is subject to change in the future.
 +
 When writing a multi-pack bitmap, `git repack` selects the largest resulting
 pack as the preferred pack for object selection by the MIDX (see

2.42.0

Sorry that this one fell off of my queue. These are both looking good to me, thanks for finding and fixing them!

Thanks,
Taylor