Re: gitattributesLarge: .gitattributes too large to parse
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Feb 28, 2023, 19:15 UTC
- Message-ID
- <Y/5SyNUbVfKFMxsf@nand.local>
- 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