Feature Request: don't limit commit-graph to 100 commits #318

New Issue

GiteaMirror · 2025-11-02T03:18:20-06:00

GiteaMirror commented

2025-11-02 03:18:20 -06:00

Originally created by @Misterke on GitHub (Feb 3, 2017).

Pull request commithgraph / timeline #428 adds a very useful graphical representation of the relationship between commits (and basically branches), but the current implementation is limited to the most recent 100 commits. Ideally, when scrolling down, the next commits should be added to the graph. Alternatively, paging could also be used (although the resulting graph doesn't give as good of an overview).

While at it, allowing to specify the ordering of the commits would be useful (switching between --date-order and --topo-order).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Originally created by @Misterke on GitHub (Feb 3, 2017). Pull request commithgraph / timeline #428 adds a very useful graphical representation of the relationship between commits (and basically branches), but the current implementation is limited to the most recent 100 commits. Ideally, when scrolling down, the next commits should be added to the graph. Alternatively, paging could also be used (although the resulting graph doesn't give as good of an overview). While at it, allowing to specify the ordering of the commits would be useful (switching between --date-order and --topo-order). <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/41619659-feature-request-don-t-limit-commit-graph-to-100-commits?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github). </bountysource-plugin>

GiteaMirror added the type/enhancement issue/stale labels 2025-11-02 03:18:20 -06:00

GiteaMirror closed this issue

2025-11-02 03:18:20 -06:00

GiteaMirror commented

2025-11-02 03:18:21 -06:00

@lunny commented on GitHub (Feb 3, 2017):

@kjellkvinge

@lunny commented on GitHub (Feb 3, 2017): @kjellkvinge

GiteaMirror commented

2025-11-02 03:18:21 -06:00

@kjellkvinge commented on GitHub (Feb 3, 2017):

I will look into this. There is some points to consider:

performance
how the js-lib will handle redraw
User experience
Complexity

I think my first approach would be something like fossil timeline:

http://fossil-scm.org/index.html/timeline

you can paginate by clicking "older", and user can set how many commits you want.

@kjellkvinge commented on GitHub (Feb 3, 2017): I will look into this. There is some points to consider: 1. performance 2. how the js-lib will handle redraw 3. User experience 4. Complexity I think my first approach would be something like fossil timeline: http://fossil-scm.org/index.html/timeline you can paginate by clicking "older", and user can set how many commits you want.

GiteaMirror commented

2025-11-02 03:18:21 -06:00

@Misterke commented on GitHub (Feb 3, 2017):

@kjellkvinge, I love the Fossil timeline visualization. The graphics look so much more "orderly" than the current commitgraph in gitea. As you pointed to it, I wonder whether getting that type of visualization would be easy/possible/difficult/out-of-the-question?

@Misterke commented on GitHub (Feb 3, 2017): @kjellkvinge, I love the Fossil timeline visualization. The graphics look so much more "orderly" than the current commitgraph in gitea. As you pointed to it, I wonder whether getting that type of visualization would be easy/possible/difficult/out-of-the-question?

GiteaMirror commented

2025-11-02 03:18:21 -06:00

@bkcsoft commented on GitHub (Feb 6, 2017):

Pagination is required. But we can scroll-load the next page...

@bkcsoft commented on GitHub (Feb 6, 2017): Pagination is required. But we can scroll-load the next page...

GiteaMirror commented

2025-11-02 03:18:21 -06:00

@Pofilo commented on GitHub (Jun 14, 2018):

I completely agree with @bkcsoft.
However, if it is to hard to implement, why not adding the 100 variable as a parameter in the configuration ?

@Pofilo commented on GitHub (Jun 14, 2018): I completely agree with @bkcsoft. However, if it is to hard to implement, why not adding the 100 variable as a parameter in the configuration ?

GiteaMirror commented

2025-11-02 03:18:22 -06:00

@stale[bot] commented on GitHub (Jan 23, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 23, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:18:22 -06:00

@stale[bot] commented on GitHub (Feb 18, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 18, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 11:43:32 -06:00

[PR #318] [MERGED] Suggested de locale fix #15302

Sign in to join this conversation.