> But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away. Not really. If you don’t care about the in

> But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away. Not really. If you don’t care about the individual commits that lead to a merge (you only care about the final merge) then you could just do `git commit --amend` through the whole process. The end result would be the same. But presumably these people (who aren’t narrowly focused on a linear history) do care. And (as you seem to be saying) sometimes you want to go down into the second parent of the merge commit. And in that history (with just merges) there’s a bunch of random “synch. points” where they merged the original branch into theirs. Why? Maybe because it had been three hours, maybe it was the start or end of the day, or something else? Can you look at the three-way diff and see why? And then there are all sorts of half thought out commits and missteps that could have been edited out if they used rebase. Using rebase does have drawbacks. But you can get back value proportional to the time you invest in it. So it’s not a simple matter of discovering that `--first-parent` is a thing and then setting an alias for that (really, you thought that would be it?). And using merges only (including synch. merges) also has its advantages. But no, using rebase is not just about hiding pull request branches.