From: Taylor Blau <me@ttaylorr.com>
To: Danny Smit <danny.smit.0@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: gitattributesLarge: .gitattributes too large to parse
Date: Tue, 28 Feb 2023 14:15:20 -0500 [thread overview]
Message-ID: <Y/5SyNUbVfKFMxsf@nand.local> (raw)
In-Reply-To: <CACoz=-x6kVGMq1oCq8-5k2Hb82DCqi94_EmX6w4_9uGXnwBLaQ@mail.gmail.com>
Hi Danny,
On Tue, Feb 28, 2023 at 05:09:01PM +0100, Danny Smit wrote:
> I couldn't find a lot of documentation about the size limitations of
> the .gitattributes file, but I did find the change that seems to have
> introduced it: https://github.com/git/git/commit/27ab4784d5c9e24345b9f5b443609cbe527c51f9
> The change describes that the file needs to be smaller than 100MB, which it is.
It's interesting that you can cause `fsck` to produce an error in the
bare repository but not in the non-bare one. Do you have
`fsck.gitattributesLarge` set to anything in the non-bare repository?
Are the affected objects in the `fsck.skipList`?
Looking at 27ab4784d5, the comment there says:
if (!buf || size > ATTR_MAX_FILE_SIZE) {
/*
* A missing buffer here is a sign that the caller found the
* blob too gigantic to load into memory. Let's just consider
* that an error.
*/
return report(options, oid, OBJ_BLOB,
FSCK_MSG_GITATTRIBUTES_LARGE,
".gitattributes too large to parse");
}
...so it's possible that the caller indeed found the blob too large to
load into memory, which would cause us to emit the ".gitattributes too
large to parse" fsck error without a .gitattributes file that actually
exceeds 100 MiB in size.
> The error seems to occur with git version 2.39.2 2.38.3, but not in
> 2.38.2.
Indeed, the change there 27ab4784d5 (fsck: implement checks for
gitattributes, 2022-12-01) exists in v2.38.3 and newer, as well as
v2.39.1 and newer. v2.38.2 was released before 27ab4784d5 existed.
> Is there a way to get rid of the message, without updating/deleting
> the file and having to rewrite the history in git?
You can suppress this message with:
$ git config fsck.gitattributesLarge ignore
Thanks,
Taylor
next prev parent reply other threads:[~2023-02-28 19:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 16:09 gitattributesLarge: .gitattributes too large to parse Danny Smit
2023-02-28 19:15 ` Taylor Blau [this message]
2023-02-28 21:30 ` Jeff King
2023-03-01 9:13 ` Danny Smit
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/5SyNUbVfKFMxsf@nand.local \
--to=me@ttaylorr.com \
--cc=danny.smit.0@gmail.com \
--cc=git@vger.kernel.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox