[seba_dos1]

Did you mean to say "less value in commit graph"?

It's literally just a matter of a single command line argument to switch between views of whole MRs and individual commits, and both those views can be incredibly useful (especially during bisection).

[sixstringtheory]

I still haven’t tried your suggestion, but would it be able to show only merge commits from PRs already merged into main, while still showing all commits on my local work branches I have in progress?

[seba_dos1]

`git log --first-parent` shows you only the list of commits accessible from HEAD by traversing their first parents. So, yes - your local work will usually have commits with just a single parent, so nothing will get skipped until it gets to merge commits.

It's also useful to skip noise if you happen to merge the upstream branch back into your topic branch for some reason.

Also, there's always `git log main..`, or even `git log main..topicbranch`. Combined with `--oneline` and perhaps `--graph`, `git log` is a really powerful tool to visualize repository state (and something that's incredibly lobotomized on popular Web frontends, unfortunately - I often end up cloning a repo to browse its history just because the Web UI is useless).

[sixstringtheory]

Thanks, that’s helpful info. I’ve been using git log --graph --oneline --decorate for a long time, so will try it with --first-parent as well!

[recursive]

What's an MR?

[seba_dos1]

Merge Request - sometimes misnamed as Pull Request.

[recursive]

What's the single command line argument you had in mind to view a whole MR after it's been merged?

[seba_dos1]

See the first comment you replied to:

> This way you don't lose commit granularity while you can still obtain the "one commit per unit of work" view with simple `git log --first-parent` (or do the opposite and skip the merge commits with `git log --no-merges`).