From: John Keeping <john@keeping•me.uk>
To: Ted Felix <ted@tedfelix•com>
Cc: git@vger•kernel.org
Subject: Re: [BUG] rebase no longer omits local commits
Date: Thu, 3 Jul 2014 20:09:17 +0100 [thread overview]
Message-ID: <20140703190917.GE13153@serenity.lan> (raw)
In-Reply-To: <53B57352.50202@tedfelix.com>
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
next prev parent reply other threads:[~2014-07-03 19:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 15:14 [BUG] rebase no longer omits local commits Ted Felix
2014-07-03 19:09 ` John Keeping [this message]
2014-07-03 22:25 ` John Keeping
2014-07-07 17:56 ` Junio C Hamano
2014-07-07 21:14 ` John Keeping
2014-07-15 19:14 ` [PATCH 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream John Keeping
2014-07-15 19:14 ` [PATCH 2/2] rebase: omit patch-identical commits with --fork-point John Keeping
2014-07-15 19:48 ` Ted Felix
2014-07-15 22:06 ` Junio C Hamano
2014-07-16 19:23 ` [PATCH v2 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream John Keeping
2014-07-16 19:23 ` [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point John Keeping
2014-07-16 20:26 ` Junio C Hamano
2014-07-16 21:27 ` John Keeping
2014-07-16 21:36 ` Ted Felix
2014-07-17 9:36 ` John Keeping
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140703190917.GE13153@serenity.lan \
--to=john@keeping$(echo .)me.uk \
--cc=git@vger$(echo .)kernel.org \
--cc=ted@tedfelix$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox