implied-commit-order: simplify the history by default

implied-commit-order: simplify the history by default

Imagine a commit history like this:

	* README: modify heading and fix a typo
	* README: modify heading
	* Add a README

where the first commit touches some parts that are touched by the second
commit, but also some others. In this case, the implied commit order
dictates that the third commit is both a direct implied parent as well
as an implied *grand* parent.

While this is technically correct, it is also confusing, and also
unnecessary when all we want to know is what commits are tied by their
changes and which ones are not: transitively-implied ancestors are just
as implied as directly-implied ones.

There is an additional problem with being "too correct" about implied
parents: our trick to re-use Git's history visualization tools is to
make temporary grafts to imply a different order than the one stored
inside the commit objects.

Now, the graft handling in Git predates the strbuf support, and
therefore it still has a rather serious line length limitation of 1023
bytes per line. Given that the graft lines *must* list non-abbreviated
commit names -- the only reason why we have to bother with long names at
all -- that leaves space for only (int)(1023 + 1) / (40 + 1) parents,
i.e. just one byte shy of allowing 24 parent commits to be listed.

While it is rare to see commit histories coming even close to merging 23
branches at once, in the implied commit order that limitation is reached
very quickly. Already Git for Windows' fork -- currently only puny 113
non-merge commits on top of upstream's 1.8.5.1 tag (a situation that is
unlikely going to change if one trusts history's lessons) -- lists
fourty-six implied parents for the final merge!

Unfortunately, simplifying the implied order isn't enough: it brings
down the (insane) number of 46 parents only to 29, still larger than
upstream Git's limit of 23 parents. But it's something!!!

While it is conceivable that there are more efficient methods to simplify
the implied commit order than to traverse the implied ancestry and
throwing out unnecessarily-implied parents, the current method is good
enough for now, and in the interest of following the YAGNI principle we'll
cross that bridge when -- and if -- we have to.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>