mbox series

[0/3] rebase: fix bug in --fork-point

Message ID 20191205225322.5529-1-alext9@gmail.com (mailing list archive)
Headers show
Series rebase: fix bug in --fork-point | expand

Message

Alex Torok Dec. 5, 2019, 10:53 p.m. UTC
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(-)