4 ms·

> There's no reason to squash when you can create merge commits from fast-forwardable state instead Sure there is. Less noise commits.

seba_dos1 3y ago
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 3y ago
  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 3y ago
    `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 3y ago
      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 3y ago
  What's an MR?
  - seba_dos1 3y ago
    Merge Request - sometimes misnamed as Pull Request.
    - recursive 3y ago
      What's the single command line argument you had in mind to view a whole MR after it's been merged?
      - seba_dos1 3y ago
        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`).

seba_dos1 3y ago

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 3y ago
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 3y ago
  `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 3y ago
    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 3y ago
What's an MR?
- seba_dos1 3y ago
  Merge Request - sometimes misnamed as Pull Request.
  - recursive 3y ago
    What's the single command line argument you had in mind to view a whole MR after it's been merged?
    - seba_dos1 3y ago
      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`).