[PATCH 0/5] optimize fast-forward checks

This is a follow-up to $gmane/204149; somehow the discussion petered out, but I think this topic (and also "tag --contains" that was not really discussed) needs to be looked into. Here is a first baby step.

 - The first one is an obvious simplification; we never supported
   more than one "reference" commits and no caller had to invent a
   loop around it to emulate multi-reference in_merge_base().

 - The two patches that follow are the uses of get_merge_bases()
   where in_merge_bases() is sufficient.  These callers are not
   interested in the merge bases between the two points; they only
   want to know if one point is an ancestor of the other.

 - The next one [4/5] should be identical to Thomas's patch.

 - The last one attempts to reduce the cost of postprocessing from
   N*(N-1) to N, but it somehow breaks 6010. I haven't looked into
   why.  They say all bugs are shallow given enough eyeballs, so I
   am sending it out to see if that is true ;-)

Junio C Hamano (5):
  in_merge_bases(): support only one "other" commit
  receive-pack: use in_merge_bases() for fast-forward check
  http-push: use in_merge_bases() for fast-forward check
  in_merge_bases(): omit unnecessary redundant common ancestor
    reduction
  (BROKEN) get_merge_bases_many(): walk from many tips in parallel

 builtin/branch.c                       |  4 +--
 builtin/fetch.c                        |  2 +-
 builtin/receive-pack.c                 |  8 +----
 commit.c                               | 60 ++++++++++++++++++++--------------
 commit.h                               |  2 +-
 contrib/examples/builtin-fetch--tool.c |  2 +-
 fast-import.c                          |  2 +-
 http-push.c                            |  3 +-
 submodule.c                            | 12 +++----
 9 files changed, 49 insertions(+), 46 deletions(-)