Re: gitattributesLarge: .gitattributes too large to parse
- From
Jeff King <peff@peff.net>
- Date
- Feb 28, 2023, 21:30 UTC
- Message-ID
- <Y/5yj8uAEM3Pz7T7@coredump.intra.peff.net>
- In-Reply-To
- <Y/5SyNUbVfKFMxsf@nand.local>
On Tue, Feb 28, 2023 at 02:15:20PM -0500, Taylor Blau wrote:
Show 28 quoted lines
> 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.I think that "!buf" case would also trigger if the size exceeded core.bigFileThreshold. It might be worth checking for that, too.
-Peff