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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
