git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Walther <cwalther@gmx.ch>
Cc: Christian Walther via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] doc: mention bigFileThreshold for packing
Date: Wed, 10 Feb 2021 14:19:16 -0800	[thread overview]
Message-ID: <xmqq5z2z1s7v.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <F63929A8-7BC9-43A7-9E7B-118433F62588@gmx.ch> (Christian Walther's message of "Wed, 10 Feb 2021 22:43:14 +0100")

Christian Walther <cwalther@gmx.ch> writes:

> Junio C Hamano wrote:
>
>> I doubt that the description of --window/--depth command line
>> options, for both repack and pack-objects, is the best place to add
>> this "Note".  Even if we were to add it as an appendix to these
>> places, please do not break the flow of explanation by inserting it
>> before the description of the default values of these options.
>
> OK. That was where I would have looked for it, because it explains
> why --window wasn't effective in my attempts to get better
> compression, but I don't insist on it - any place would have
> worked, as I read both manpages back and forth several times.

The "pack-objects" command (and to some degree "repack", too) is
about packing throughout, and --depth/--window is not necessarily
the central piece of the puzzle, and that, together with disruption
of the flow of the original explanation, was the reason why I found
the initial location a bit odd.

> In git-repack.txt, there is a "Configuration" section at the
> bottom, I guess it would fit there? There is none in
> git-pack-objects.txt, but I could add it. What do you think?

You're right---if there is an existing CONFIGURATION section, that
may be a much better place.  There are configuration variables that
affect how the packing works other than the core.bigFileThreshold,
and attributes like "delta" would also affect the outcome.

Describing all in one CONFIGURATION section would be valuable.

What I queued is with the following ready to be squashed in,
primarily because I was lazy and didn't have time/inclination to
look for a better place myself ;-)

Thanks.

---- >8 ----
Subject: [PATCH] fixup! doc: mention bigFileThreshold for packing

---
 Documentation/git-pack-objects.txt | 7 +++----
 Documentation/git-repack.txt       | 7 +++----
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 59150ded4b..be0f953c35 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -97,12 +97,11 @@ base-name::
 	side, because delta data needs to be applied that many
 	times to get to the necessary object.
 +
-Note that delta compression is never used on objects larger than the
-`core.bigFileThreshold` configuration variable (see
-linkgit:git-config[1]).
-+
 The default value for --window is 10 and --depth is 50. The maximum
 depth is 4095.
++
+Note that delta compression is never used on objects larger than the
+`core.bigFileThreshold` configuration variable (see linkgit:git-config[1]).
 
 --window-memory=<n>::
 	This option provides an additional limit on top of `--window`;
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 0a7038ec4a..145fff6e01 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -96,12 +96,11 @@ to the new separate pack will be written.
 	affects the performance on the unpacker side, because delta data needs
 	to be applied that many times to get to the necessary object.
 +
-Note that delta compression is never used on objects larger than the
-`core.bigFileThreshold` configuration variable (see
-linkgit:git-config[1]).
-+
 The default value for --window is 10 and --depth is 50. The maximum
 depth is 4095.
++
+Note that delta compression is never used on objects larger than the
+`core.bigFileThreshold` configuration variable (see linkgit:git-config[1]).
 
 --threads=<n>::
 	This option is passed through to `git pack-objects`.
-- 
2.30.1-597-g82b686dd6a


  reply	other threads:[~2021-02-10 22:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 19:07 [PATCH] doc: mention bigFileThreshold for packing Christian Walther via GitGitGadget
2021-02-09 21:50 ` Junio C Hamano
2021-02-10 21:43   ` Christian Walther
2021-02-10 22:19     ` Junio C Hamano [this message]
2021-02-21 13:23 ` [PATCH v2] " Christian Walther via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq5z2z1s7v.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=cwalther@gmx.ch \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).