git rebase --fork-point with a short branch ref name (without refs/heads/ prefix) for the upstream will not use the fork point between the upstream and the branch. If git rebase --forkpoint is used with a full ref on the upstream (refs/heads/branchName), the fork point between the branch and upstream is correctly used. This bug was introduced in 2.20.0 with the c implementation of rebase. I was able to reproduce it on next and master. The code path for rebase with --fork-point and a user-provided upstream does not use a DWIM method to look up the full ref name. This leads to get_fork_point returning a null pointer and rebase using the upstream itself instead of the fork point between the upstream and branch. I looked in other places that call get_fork_point and found that in handle_fork_point of builtin/merge_base.c, dwim_ref is used to find the full ref name before calling get_fork_point. I initially based this change off of maint, but then saw that there were some tests added for rebase --fork-point on master, so I rebased onto there to build off of those tests, but I'm not sure if that was the "right" thing to do. Alex Torok (3): rebase: add test for rebase --fork-point with short upstream rebase: refactor dwim_ref_or_die from merge-base.c rebase: fix rebase to use full ref to find fork-point builtin/merge-base.c | 9 +-------- builtin/rebase.c | 4 +++- refs.c | 14 ++++++++++++++ refs.h | 1 + t/t3431-rebase-fork-point.sh | 1 + 5 files changed, 20 insertions(+), 9 deletions(-) -- 2.17.1
