Large Commits cause out of memory errors about gitlist

[nifisher]

I'm not sure I really expect this issue to be fixed per se, but I figure it should be handled with more grace. If the commit and patch can be broken up into pages easily that would be spectacular (possibly better than one large page of diffs anyhow). If the patch is dropped and just the commit message is displayed that would be understandable. Pretty much anything other than the current behavior.

[klaussilveira]

This means that PHP exceeded it's memory limit, which is expected with huge repositories. Try increasing some MBs in your php.ini.

[nifisher]

While a completely reasonable response on your part, and one that takes away the fire from my raised issue, I must ask, is it reasonable for gitlist to be using more than 128MB of memory when loading a commit?

[klaussilveira]

I don't see pagination (like we do in the commit history) as an alternative for the commit details page. If the commit is huge, what can be done to show properly?

[nifisher]

hmm... apparently 512M wasn't enough

Just to put numbers on this:
$ git show HEAD^ | wc
2123294 9608479 77890168

And for people like me who won't remember what the output of wc is later:
2123294 -- lines
9608479 -- words
77890168 -- bytes/characters

If I am not mistaken, the bulk of that count is pretty much entirely the patch/diff. I was thinking pagination would work between the seperate patches would work (keeping the commit message on top, so prev/next would scroll through the patches). This assumes that someone isn't checking in a single patch of that size, but I figure that's a safe assumption (binary files might cause a problem with that assumption maybe).

If it doesn't work on your mind, that's fine. Like I said, if the page comes up and it prints the commit message and a statement of "there are too many differences to display" or "the patch is too large to display"

Perhaps someone else might have a better idea. How does GitWeb handle this? I don't have GitWeb installed so I don't know.

[klaussilveira]

Well, i believe that implementing a behavior that identifies the size of the commit and decides t paginate or not is the best course of action. Displaying "too large to display" is a major turn off. This is on the TODO! :)

[nifisher]

I figured this case was an outlier but probably one not considered originally. Thanks, sir.

[sstok]

Github handles this by only showing the file-list and not the actual diffs.
And when just at the limit, only showing some files my browser freezes for a moment, so not only will it crash php but also the browser. We cant handle everything ;)

One thing that might by interesting though, is to show the diff on command using Ajax (when the whole diff is to big).
When some presses view diff , the file diff get loaded on demand, idea?

[klaussilveira]

That's probably a much better solution, if the diff has more than X files, display only the names and lazy-load the damn thing.

I have created a more specific and detailed issue here: #161