-
Notifications
You must be signed in to change notification settings - Fork 31
Remove pager #131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove pager #131
Conversation
ivanquero@github provided a homebrew formula for git-graph See Homebrew/homebrew-core#210627
|
I am not 100% happy with removing the pager, particularly because there is a lack of tools that can be used as a replacement on Windows. But I will not oppose the change. |
|
It might be reasonable to hold off on merging this until we're sure the next release will be a major version bump, not a minor or patch bump, e.g. when we refactor the repo layout and/or rename the binaries. |
|
As far as I can tell, every feature the pager has today is present in I normally use less from GnuWin when on Windows. |
|
@mlange-42 can we allow merge commits on this repo? |
Yes, of course. I prefer linear history and it is also more fair regarding contributor statistics, but go ahead. |
How do you figure that? I'm not aware of how branch merging is less fair to contributors. Personally I use all three merge strategies in my projects on a case-by-case basis, generally preferring to merge when PRs have branches with nicely curated commit messages where the history makes sense to keep but the branch is also a discrete related unit of work, squashing PRs when they are just piles of fixup commits, and rebasing to be linear for single-commit PRs or where unrelated commits have been jumbled together in a branch for no reason. |
|
Not 100% sure, but if someone makes a branch with dozens of small commits and you don't squash, I think all these commits will be counted in the stats, which can be abused. So one contribution == one merged PR seems more fair. But personally, I don't care about my "contribution stats". |
|
I have been working on a new backend for git-graph for about 6 months now
-on and off, but i have started over 3 times. All that work does not count
anywhere in any of these models.
I think the important credit is given when you talk with people and get a
feeling that you help each other and it is appreciated.
ons. 19. nov. 2025 12.42 skrev Martin Lange ***@***.***>:
… *mlange-42* left a comment (mlange-42/git-graph#131)
<#131 (comment)>
Not 100% sure, but if someone makes a branch with dozens of small commits
and you don't squash, all these commits will be counted in the stats, which
can be abused. So one contribution == one merged PR seems more fair. But
personally, I don't care about my "contribution stats".
—
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAB7VZLJXYVX7XS7JP3QAL35RJS5AVCNFSM6AAAAACMI5G2PWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNJSGIZTOMJZG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This feature is a non-feature - it removes the paging code.
This is to focus the CLI tool on generating the graph, not on interaction.
For interactive use, see git-igitt.