[paulddraper]

But a rebased commit can also have arbitrary changes!

---

P.S. Any commit can have any change. Or no change.

A "commit" is a version...a message, a tree, some metadata, and 0 or more parents. In fact it's not even a change/diff/patchset per se. Though will often compare it against its assigned parents. If it has multiple parents, you'd have to choose which to compare. If it has zero parents, you can't compare against any parents.

[ptsneves]

Yes, except git log will show all the commits that got into the branch, while with merge you need git log -m otherwise there are invisible commits(and diffs) in a pretty common workflow. I don’t know why this is the default behaviour.

Git log only shows one tree not parallel trees from the merge.

[paulddraper]

? Not sure what you mean.

git log will show all ancestors.

And git diff shows any difference between two refs.

Nothing invisible unless you deliberately make it so.

[PhilipRoman]

Git log (and many other tools as well) pretend that merge commits do not introduce changes. I learned about it in the hard way when someone managed to implement an entirely new feature, contained within a hidden merge commit.

It's only partially the fault of Git - the entire idea of a merge requires new concepts like 3-way diff, which are not needed for rebased commits. I'm not even sure that most software like GitHub can display such a diff.

[tsimionescu]

The blog post explains it pretty clearly: git log -p doesn't show the diff for those merge commits like it does for a normal commit.