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.
>
> I've bisected this down to commit bb3f458: "rebase: fix fork-point with
> zero arguments". The attached script reproduces the problem. Reverting
> the aforementioned commit fixes the problem.
>
> A failed run of this script will result in conflicts. A successful run
> against master with bb3f458 reverted ends as follows:
>
> From /tmp/rebase-issue/maint
> fe401cd..955af04 master -> origin/master
> fatal: Not a valid object name: ''
> First, rewinding head to replay your work on top of it...
> Applying: Third change
>
> (I'm not sure if that "fatal: Not a valid object name: ''" is of any
> concern. It started appearing for me at some point during the bisect.)
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) and makes `git rebase` match the behaviour of
`git pull --rebase` so that:
git fetch &&
git rebase
really is equivalent to:
git pull --rebase
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html