Exactly. And if the default view of `git log` wasn't so terrible (if it acted like git log --first-parent), then I think a lot more people would do that too.
But I understand why people who just use `git log` complain with merge commits. It is frustratingly hard to see what actually happened, because subcommits from that merge branch show up in the past in your linear timeline and aren't grouped together. It clutters your log and makes it really hard to tell what is going on and what commits are related to each other.
bazaar's (now called breezy) log (which we used before moving to git) was really nice. By default, it only showed first parents (direct commits or merges). And if you wanted to see more than that, it grouped merges together. This is what happens when you call `bzr log --include-merged` to show not just the top level merges/commits, but also the sub-commits from each merge:
------------------------------------------------------------
revno: 33 [merge]
committer: John Doe <john.doe@example.com>
branch nick: master
timestamp: Tue 2013-09-03 11:39:37 -0500
message:
Fixed bug #413 - Add in a blend option
------------------------------------------------------------
revno: 32.1.2
committer: John Doe <john.doe@example.com>
branch nick: fix-413
timestamp: Tue 2013-09-03 10:07:03 -0500
message:
Merged the Role changes from fix-412
------------------------------------------------------------
revno: 32.1.1
committer: John Doe <john.doe@example.com>
branch nick: fix-413
timestamp: Tue 2013-09-01 10:04:28 -0500
message:
Some initial work on a blend mode
------------------------------------------------------------
revno: 32 [merge]
committer: John Doe <john.doe@example.com>
branch nick: master
timestamp: Tue 2013-09-03 09:17:27 -0500
message:
Fixed bug #408 - Make the interface prettier
------------------------------------------------------------
revno: 29.2.3 [merge]
committer: John Doe <john.doe@example.com>
branch nick: fix-408
timestamp: Wed 2013-09-02 15:31:32 -0500
message:
mft
------------------------------------------------------------
revno: 29.2.2
committer: John Doe <john.doe@example.com>
branch nick: fix-408
timestamp: Wed 2013-08-24 12:13:17 -0500
message:
Fixed multiline support
------------------------------------------------------------
revno: 29.2.1
committer: John Doe <john.doe@example.com>
branch nick: fix-408
timestamp: Wed 2013-08-22 11:58:48 -0500
message:
Added directories for other layouts. Changed out the logo, and force a size during the signon
------------------------------------------------------------
revno: 31 [merge]
committer: John Doe <john.doe@example.com>
branch nick: master
timestamp: Wed 2013-08-28 15:13:24 -0500
message:
Fixed bug #404 - Pressing back in the preferences exits the application
------------------------------------------------------------
revno: 30.1.1
committer: John Doe <john.doe@example.com>
branch nick: fix-404
timestamp: Wed 2013-08-28 15:11:24 -0500
message:
Got rid of the no history junk. It looks like the problem can be solved by calling finish
The top level merges are in order by commit/date, while the sub-commits in each branch and in order with respect to their parent, not the entire repo!
This even resolves stuff, like in revno 29.2.3 where the master branch is merged into the feature branch (fix-408) to get fix-408 up to date.
Comments
Exactly. And if the default view of `git log` wasn't so terrible (if it acted like git log --first-parent), then I think a lot more people would do that too.
But I understand why people who just use `git log` complain with merge commits. It is frustratingly hard to see what actually happened, because subcommits from that merge branch show up in the past in your linear timeline and aren't grouped together. It clutters your log and makes it really hard to tell what is going on and what commits are related to each other.
bazaar's (now called breezy) log (which we used before moving to git) was really nice. By default, it only showed first parents (direct commits or merges). And if you wanted to see more than that, it grouped merges together. This is what happens when you call `bzr log --include-merged` to show not just the top level merges/commits, but also the sub-commits from each merge:
The top level merges are in order by commit/date, while the sub-commits in each branch and in order with respect to their parent, not the entire repo!This even resolves stuff, like in revno 29.2.3 where the master branch is merged into the feature branch (fix-408) to get fix-408 up to date.