Re: [git-sizer] Implications of a large commit object

From: Jeff King <peff@peff.net>
Date: Mar 14, 2018, 14:56 UTC
Message-ID: <20180314145623.GB15531@sigill.intra.peff.net>
In-Reply-To: <CAMy9T_GdYjUm9DqcgrC=NxyTbZk_ep5rvAAK2J=zwhiSMyvaLA@mail.gmail.com>

On Wed, Mar 14, 2018 at 09:33:32AM +0100, Michael Haggerty wrote:

Show 8 quoted lines

> Maybe your migration tool created a huge commit message, for example
> listing each of the files that was changed.
> 
> AFAIK this won't cause Git itself any problems, but it's likely to be
> inconvenient. For example, when you type `git log` and 7 million
> characters page by. Or when you use some GUI tool to view your history
> and it performs badly because it wasn't built to handle such enormous
> commit messages.

Probably one such commit won't break the bank, but it will make history traversals that cross it slower (e.g., "--contains", merge-bases, etc). We'll load the whole 7MB object just to find its parents. If you imagine the average commit object is more like 1k and that current traversals bottleneck on loading the commit object bytes (both of which I think are roughly accurate), then crossing that one commit in a traversal is equivalent to crossing 7000 "normal" commits in cost.

At least until Stolee's serialized commit graph work is merged, at which point it will only be expensive if we actually try to show the commit message for that particular object.

-Peff