You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The bug is due to the implementation of -n. GitGraph::new counts off the desired number of commits before the final filtering of unused commits. This means that the displayed number of commits often is lower than the requested number.
To get an accurate number, while saving effort and doing the unused filtering, the code should add commits until the limit is reached. This is similar to the behavior of an incremental load of commits.
The bug is due to the implementation of -n. GitGraph::new counts off the desired number of commits before the final filtering of unused commits. This means that the displayed number of commits often is lower than the requested number.
To get an accurate number, while saving effort and doing the unused filtering, the code should add commits until the limit is reached. This is similar to the behavior of an incremental load of commits.
Are you sure? The PR that introduced the bug only changes main.rs.
At this commit I get no output from git-graph -n 5, nor from git-graph, but git-graph --no-pager -n 5 worked as expected. I think there may be a second bug, related to the pager. I have not investigated that bug.
Same issue here. Likely the pager doesn't print anything if the # of commits is not large enough since it doesn't fill a page? Hence for small repos with few commits they are not shown unless the paper is turned off. Like a simple fix to this would be to detect the number of commits and if it is below the paging threshold then simply execute the no-pager branch.
Alternatively, just print whatever buffer it is accumulating rather than ignoring it.
Activity
peso commentedon Sep 22, 2025
The bug is due to the implementation of -n. GitGraph::new counts off the desired number of commits before the final filtering of unused commits. This means that the displayed number of commits often is lower than the requested number.
To get an accurate number, while saving effort and doing the unused filtering, the code should add commits until the limit is reached. This is similar to the behavior of an incremental load of commits.
mlange-42 commentedon Sep 23, 2025
Are you sure? The PR that introduced the bug only changes
main.rs.peso commentedon Sep 23, 2025
The bug related to -n depends on the repository. I do not yet have a script that can reproduce it.
Regarding commit d018124 "Add scroll up (#101)"
At this commit I get no output from
git-graph -n 5, nor fromgit-graph, butgit-graph --no-pager -n 5worked as expected. I think there may be a second bug, related to the pager. I have not investigated that bug.Universal-Invariant commentedon Oct 9, 2025
Same issue here. Likely the pager doesn't print anything if the # of commits is not large enough since it doesn't fill a page? Hence for small repos with few commits they are not shown unless the paper is turned off. Like a simple fix to this would be to detect the number of commits and if it is below the paging threshold then simply execute the no-pager branch.
Alternatively, just print whatever buffer it is accumulating rather than ignoring it.