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.
Summary: | Increase Show History default limit | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | hifi |
Component: | Git | Assignee: | Ondrej Vrabec <ovrabec> |
Status: | NEW --- | ||
Severity: | normal | CC: | git |
Priority: | P3 | ||
Version: | 8.0.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
hifi
2015-03-02 16:02:36 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? 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. i'll change it to 20. Regarding the endless scrolling - well, i'll consider that. |