Teemu Likonen <tlikonen@xxxxxx> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
