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(-)
--
1.7.12.116.g31e0100
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
