Skip to content

Conversation

@peso
Copy link
Collaborator

@peso peso commented Nov 17, 2025

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.

peso added 2 commits November 17, 2025 00:15
ivanquero@github provided a homebrew formula for git-graph
See Homebrew/homebrew-core#210627
The git-graph command line tool should be kept simple.
Other applications, like less, does a better job
at paging long outputs.
@mlange-42
Copy link
Owner

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.

@alerque
Copy link
Contributor

alerque commented Nov 17, 2025

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.

@peso
Copy link
Collaborator Author

peso commented Nov 17, 2025

As far as I can tell, every feature the pager has today is present in less. Did I overlook something?

I normally use less from GnuWin when on Windows.
There is also a chocolatey package less.

@peso
Copy link
Collaborator Author

peso commented Nov 18, 2025

@mlange-42 can we allow merge commits on this repo?
This is really the use case which git-graph was built for, so we ought to use it ourselves.

@mlange-42
Copy link
Owner

@mlange-42 can we allow merge commits on this repo? This is really the use case which git-graph was built for, so we ought to use it ourselves.

Yes, of course. I prefer linear history and it is also more fair regarding contributor statistics, but go ahead.

@alerque
Copy link
Contributor

alerque commented Nov 19, 2025

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.

@mlange-42
Copy link
Owner

mlange-42 commented Nov 19, 2025

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".

@peso
Copy link
Collaborator Author

peso commented Nov 19, 2025 via email

@peso peso merged commit 4ab7bf0 into master Nov 24, 2025
5 checks passed
@peso peso deleted the feature/no-pager branch November 24, 2025 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants