Flexible commit loading (intended for large repos)

[vivien]

With graph=no-topo, the startup delay issue is fixed indeed. But the lag due to the commit loading (described in #366) still exists. We may want to make the loading flexible, that would make Tig very handy with large repos. What I could imagine is:

• have a max-loading=X option to make Tig stop loading after X commits (1000 is done in less than .5s and is quite enough).
• remember the number of loaded commits and add a load action to fetch X more commits.

Use case: imagine to stop loading with z or set a max to 36, then trying to go beyong the last line will try to load more commits instead of directly displaying "Cannot move beyond the last line".

A default value of max-loading=0 would mean "fetch all".

N.B.: in addition to sourceable contributed vim.tigrc or emacs.tigrc (as mentioned in #273), we may add a convenient contrib/large.tigrc file which sets graph=no-topo and max-loading=1000 for instance.

[jonas]

Instead of a max-loading option, could we do with a main-options which would work similar to blame-options and diff-options? You could then have set main-options = -n1000 to only load one thousand commits.

I like the ideas of offering a contrib/large.tigrc.

[jonas]

The load action could use git-log's --skip=<number> option, but it would be tricky to get this to work with the graph since it only stores the rendered representation.

[vivien]

Sure for the main-options! I wasn't really aware of the implementation, this was just a raw idea. I didn't know about the --skip option neither. For the graph, I think it is acceptable to warn about the broken graph, since limiting the number of commits with graph together hardly makes sense. (I'd suggest the large.tigrc file to set commit-title-graph = no)

[pkitszel]

This issue is so old, that an update on state of the matters would be welcomed.

[krobelus]

I just use something like tig origin/master@{1}..