It crashes with medium/large/big repo

[perettigiuliano]

Hi, I have just tried with this repo: Switft from apple
git-graph crashes:

Could you fix that?

Thanks

[perettigiuliano]

@mlange-42
Do you think that you can do something to prevent git-graph to crash on such a projects?

[mlange-42]

Hi @perettigiuliano! Thank you for reporting! Unfortunately, I did not find the time to look into this yet. As I have no idea so far what exactly causes the crash, it is hard to judge. But surely this can be fixed somehow.

[mlange-42]

@perettigiuliano As a temporary workaround, use the -n option to limit the number of commits to show.

It looks like this is not really a bug. The number of commits is just too big to fit their internal representation into the memory. Not sure how to continue here. Maybe a default limit to the number of commits would be an option.

[perettigiuliano]

@mlange-42
Thank you for the answer, here it is the last wmanil that I have received from support of "Fork" application, after mine asking them to have in their application a graph like the one from yours.

Giuliano,

Thank you for trying!

That repo is insane, I have never seen a repo like that!!!

Swift is just a normal repo, it's not *that* big. There are many repos of a similar size, VSCode (https://github.com/microsoft/vscode.git), for example.

Just as a reference, the Chromium repo IS insane :).


Graph drawing is a very difficult and complex problem (especially when we talk about production quality).

What we have in Fork now is a compromise between readability and performance.

It's great though, that there is interest in improving the graph visualization 👍. I myself spent a lot of time trying to improve it and honestly failed :(.

Has "git-graph" some memory allocation problem? Is it related to a (or more) bug or to the logic implied in a graphic like that?

It's not related to the memory allocation, I think. It's more O(n) problem.

Some hot points I noticed:
- git graph is a DAG, which means commits only have pointers to *parents*. Traversing commit *children* contradicts git design. And as result, calculating children for each commit requires full graph traversing, which will likely be bottleneck on large repos.
- many repos have a lot of tags (> 10K in some repos) and their number *always* grow. Taking them into account is very-very expensive.
- full traversing makes impossible lazy loading. For example, it's impossible to show first 100 commits of 'swift' in a reasonable time

Generally speaking, I'm not sure if git references (both branches and tags) should be part of the graph visualization algorithm. Branches in git are not graph 'edges', instead they are graph 'tips'. So, again, handling them as 'edges' contradicts git design and will likely be a bottleneck.

Dan

Maybe there something that could serve as suggestion...
Surely a limit, as I saw the same request is coming also from other issues. could be a work around, something like taking only from the moment of actual branch creation on,