On Wed, Jun 21, 2017 at 6:51 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Apr 20, 2017 at 05:02:55PM -0400, Jeff King wrote:
>
>> > git-compat-util.h | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> This probably needs an update to the core.packedGitLimit section of
>> Documentation/config.txt.
>
> Looks like we never did that part. Here it is (Junio, this goes on top
> of dt/raise-core-packed-git-limit).
>
> -- >8 --
> Subject: [PATCH] docs: update 64-bit core.packedGitLimit default
>
> We bumped the default in be4ca2905 (Increase
> core.packedGitLimit, 2017-04-20) but never adjusted the
> documentation to match.
>
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> Documentation/config.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f6278a5ae..fc2cf1fe1 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -683,7 +683,8 @@ core.packedGitLimit::
> bytes at once to complete an operation it will unmap existing
> regions to reclaim virtual address space within the process.
> +
> -Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
> +Default is 256 MiB on 32 bit platforms and 32 TiB (effectively
> +unlimited) on 64 bit platforms.
nit: I would have not written "effectively unlimited", as we state
the limit right here. The further sentences already sooth the
user to not worry to much:
This should be reasonable for all users/operating systems,
except on the largest projects. You probably do not need to
adjust this value.
But as we just adjusted the default to prevent a bug,
maybe there are good reasons to adjust the value for users,
too? (Specifically 32 bit platforms could run into the problem
that the commit be4ca2905 (Increase core.packedGitLimit,
2017-04-20) states.)
While I think this patch is worthwhile applying (even as-is),
I think we might want to put another patch here?
Or is there a way to fix the underlying issue when fetch and
repack is run at the same time?
