Re: [BUG] rebase no longer omits local commits

[John Keeping <john@keeping.me.uk>]

On Thu, Jul 03, 2014 at 08:09:17PM +0100, John Keeping wrote:
> On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:
> > Starting with git 1.9.0, rebase no longer omits local commits that 
> > appear in both the upstream and local branches.
> 
> It is the problem that bb3f458 fixes.  The change in behaviour is
> actually introduced by ad8261d (rebase: use reflog to find common base
> with upstream).
> 
> In your example, I think this is working as designed.  You can restore
> the previous behaviour either with `git rebase --no-fork-point` or with
> `git rebase @{u}`.
> 
> The change is designed to help users recover from an upstream rebase, as
> described in the "DISCUSSION ON FORK-POINT MODE" section of
> git-merge-base(1).

Having thought about this a bit more, I think the case you've identified
is an unexpected side effect of that commit.

Perhaps we shuld do something like this (which passes the test suite):

-- >8 --
diff --git a/git-rebase.sh b/git-rebase.sh
index 06c810b..0c6c5d3 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -544,7 +544,8 @@ if test "$fork_point" = t
 then
 	new_upstream=$(git merge-base --fork-point "$upstream_name" \
 			"${switch_to:-HEAD}")
-	if test -n "$new_upstream"
+	if test -n "$new_upstream" &&
+	   ! git merge-base --is-ancestor "$new_upstream" "$upstream_name"
 	then
 		upstream=$new_upstream
 	fi
-- 8< --

Since the intent of `--fork-point` is to find the best starting point
for the "$upstream...$orig_head" range, if the fork point is behind the
new location of the upstream then should we leave the upstream as it
was?

I haven't thought through this completely, but it seems like we should
be doing a check like the above, at least when we're in
"$fork_point=auto" mode.