5 ms·

Merge commits are noise, a clean history is has no merge commits

• NateEag 6y ago
  git log --no-merges
  • leejo 6y ago
    See also git log --no-merges --first-parent I don't get the "no merge commits" argument - git log has dozens of options allowing you to bend it to your use case. To address the grand parent that "a clean history is has no merge commits" I would argue that a clean history is also a lie if you're working in a branching workflow (hint: you should be working in that most of the time). If you want to avoid (note: not eliminate) merge commits then make sure to rebase against master before merging, and then ensure merges are fast-forward merges.
• aurelianito 6y ago
  If you squash all the merge requests, you get ONLY merge commits.
  • Droobfest 6y ago
    They can both be pretty useful. So keep all commits and decide upon viewing the log which ones you really want to see.
  • OJFord 6y ago
    A 'merge commit' is the commit that ties together two strands. * merge commit |\ | * branch work | | | * branch work |/ * If you squash to merge, typically you're also going to rebase it (equivalently, if it's more familiar, cherry-pick the squash onto the branch your 'merging' it into). * squash cherry-picked / rebased | * both branch works squashed | * | branch work | | | | * | branch work |/_/ * (In this case the target branch could have been fast-forwarded, but this also works if there's some other work on the mean time:) * squash cherry-picked / rebased | * something unrelated | * both branch works squashed | * | branch work | | | | * | branch work |/_/ *
    • aurelianito 6y ago
      I know. It means that the only commits left are the ones that originally where merge requests, and you loose the rest of the history.
• l72 6y ago
  I think this depends on your policy. The policy at my work place is that every commit into master is always a merge commit. When looking at the git logs, we then always do: git log --first-parent This only shows the top level commits (either a direct commit or a merge commit) and doesn't show any of the subcommits in the branches. This gives us a very clean history, something like: commit ce29331f7da82ce528ca6e437b8893248a842169 Merge: a14522cbf 936ef9f90 Author: Joe Sample <joe.sample@example.com Date: Tue Jul 7 14:34:20 2020 -0500 ISS-2047 - Add ids to user invitation or creation commit a14522cbf32487dc590c8b6f3332d3fc9371a640 Merge: d08342170 cb94a86b1 Author: Jane Dow <jane.doe@example.com Date: Tue Jul 7 14:28:28 2020 -0500 ISS-2032 - If an enterprise is disabled, their api keys should be disabled commit d083421702e3ff50bc4c62e85b687e172e4bfe76 Merge: 0d167d25e ba3900a4a Author: Joe Sample <joe.sample@example.com> Date: Tue Jul 7 14:25:41 2020 -0500 ISS-2045 - Return a reason of why the invitation was auto-cancelled Then if I want to see everything that happened in the branch that was merged in, I can just run: git log d083421702e3ff50bc4c62e85b687e172e4bfe76^..d083421702e3ff50bc4c62e85b687e172e4bfe76 and see all the commits that were in that feature branch. No need to squash things or hide them. I really wish git, by default, showed commits under a merge as a tree, rather than as a flat list. This is what bazaar (bzr now breezy) did, and it made a lot more sense when looking at the history.