merge-base: teach "--fork-point" mode
commitd96855ff517560650c62eca51a8bb78263f6a3ef
authorJunio C Hamano <gitster@pobox.com>
Wed, 23 Oct 2013 23:47:32 +0000 (23 16:47 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 29 Oct 2013 20:06:08 +0000 (29 13:06 -0700)
tree6fb9e42186c21d95b9c86af87eb8f8ed7a80d028
parent16e57aec7f672fabe38fa0e4d39252eb9c7a1563
merge-base: teach "--fork-point" mode

The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt.  For example, if the history looked like this:

                     o---B1
                    /
    ---o---o---B2--o---o---o---Base
            \
             B3
              \
               Derived

where the current tip of the "base" branch is at Base, but earlier
fetch observed that its tip used to be B3 and then B2 and then B1
before getting to the current commit, and the branch being rebased
on top of the latest "base" is based on commit B3, it tries to find
B3 by going through the output of "git rev-list --reflog base" (i.e.
Base, B1, B2, B3) until it finds a commit that is an ancestor of the
current tip "Derived".

Internally, we have get_merge_bases_many() that can compute this
with one-go.  We would want a merge-base between Derived and a
fictitious merge commit that would result by merging all the
historical tips of "base".  When such a commit exist, we should get
a single result, which exactly match one of the reflog entries of
"base".

Teach "git merge-base" a new mode, "--fork-point", to compute
exactly that.

Helped-by: Martin von Zweigbergk <martinvonz@gmail.com>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-merge-base.txt
builtin/merge-base.c
t/t6010-merge-base.sh