Handling repos with large commit histories

This session focused on making gitscope stay responsive when opened in repositories with larger commit histories. The app now loads commit history incrementally instead of assuming the entire log can be fetched at startup.

What Changed

• Added bounded commit loading with an initial page size.
• Requested one extra commit per page so the UI can tell whether more history is available.
• Added a manual “load more” action for extending the visible history.
• Added automatic loading near the end of the currently loaded rows during keyboard navigation.
• Added status bar feedback for loading, more-history, and end-of-history states.
• Kept current branch/HEAD and all-branches views on the same paginated backend path.
• Preserved selected-commit behavior as new pages are appended.

Why It Matters

Before this work, a very large repository could force the app to ask git for too much history up front. The updated behavior keeps startup bounded by the first page of commits, then loads additional pages only when the user asks for or navigates into them.

That keeps gitscope aligned with its core goal: a fast local read-only history viewer, not a heavyweight repository indexer.

Testing

Added and expanded tests around:

• initial log loading staying bounded by page size
• manual page loading appending rows
• load-more stopping cleanly at the end of history
• navigation near the loaded boundary requesting another page
• all-branches loading using the same pagination window

Read-Only Review

The UI still does not call git directly. It asks the backend for paged commit data, selected-commit diffs, refs, and HEAD information only.

No checkout, staging, committing, branch mutation, remote operation, or network behavior was added.

Verification

• py -m pytest passed with 31 tests.
• Source installation continued to work.
• The app could be mounted against the local gitscope repository with populated refs, log rows, selected commit, diff output, and status text.