This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 250822 - Increase Show History default limit
Summary: Increase Show History default limit
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Git (show other bugs)
Version: 8.0.2
Hardware: All All
: P3 normal (vote)
Assignee: Ondrej Vrabec
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-02 16:02 UTC by hifi
Modified: 2015-03-02 16:46 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hifi 2015-03-02 16:02:36 UTC
The default for Show History is as small as only 10 commits. It is rarely enough even with recent history and I've had to hit the "Show more... 50" link almost every time to get useful output.

Increasing this to something like 100 would be much more useful and there shouldn't be much of a performance issue with Git as it's all local anyway. Even with a large repo it takes under a second on my lousy machine to show 100 commits.

I presume the limit of 10 comes from Subversion or CVS where the server actually needs to do something resource intensive to get some history out?
Comment 1 Ondrej Vrabec 2015-03-02 16:27:59 UTC
(In reply to hifi from comment #0)
> I presume the limit of 10 comes from Subversion or CVS where the server
> actually needs to do something resource intensive to get some history out?
You'll be surprised but it originated in Mercurial support. When showing history for a specific file or folder the computation is rather expensive and complex o increasing to 100 is definitely not an option.
The default could probably be 100 if searching history repository-wide (on the whole repo without a folder context). However not sure what information that gives you. In most cases you want to see most recent commits so past 100 commits would just get in the way, wouldn't they?
Comment 2 hifi 2015-03-02 16:37:58 UTC
You're right that 100 would probably be expensive if you need to do it per file basis also with git because of how the history is constructed. Repository wide it's fast.

100 was just a number that is much larger than 10 which is way low even with recent history. Even 20 would be more suitable.

Could infiniscroll be implemented and the amount of commits that actually fits your view doubled be the default (that would be around 20 anyway tops for most people)? When scrolling to bottom the next full view amount of commits would be automatically fetched so you can keep scrolling as much as you want. That would be the best user experience I can think of.
Comment 3 Ondrej Vrabec 2015-03-02 16:46:18 UTC
i'll change it to 20. Regarding the endless scrolling - well, i'll consider that.