Re: log --graph --first-parent weirdness

Teemu Likonen [off-list ref] writes:

Well, I disagree :-) Merges are interesting points in history (they
introduce features etc.) and for a "--graph --first-parent" user
a certain already known merge is easier to find if there is a stable
identifier for them.

Step back a bit.  Regular commits also introduce features.  If you want to
argue for marking a merge as more significant than single parent commits,
you need to justify the reason why a bit better.

When you are looking at a history (be it 'first-parent' or regular), each
transition introduces changes, but especially when you are talking about
first-parent, a merge is merely a squashed commit of everything that
happened on the side branch, which may be trivial one-liner fix or an
addition of full new command.  Why a merge of trivial one-liner fix should
be treated as more significant than a more involved change that directly
was done on the master branch?

A full and perfect implementation of a new command may have happened on a
side branch as a single commit.  If the master branch was dormant while it
was being done, the final merge of that side branch will result in a
fast-forward, and the introduction of the new command would appear as a
non-merge, regular commit.  If on the other hand there were activities on
master since the side branch forked, the introduction of the new command
would appear as a merge.  Why do you paint the latter as more significant
than the former?

If somebody argues for making the marking different (perhaps by color-code
the asterisk differently) depending on how much each commit changes the
tree relative to its parents, I would say it might be a great feature.
Such a display would treat the two cases I mentioned above equally.

I however do not think the number of recorded parents deserves such a
special treatment to clutter the output and distract people, especially
when "is it a merge?" can be easily seen by two other means (log message
and graph lines).