Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f
- From
Sverre Rabbelier <srabbelier@gmail.com>
- Date
- Feb 12, 2009, 20:44 UTC
- Message-ID
- <bd6139dc0902121244i4f894209m37f6c80716cbc397@mail.gmail.com>
- In-Reply-To
- <alpine.DEB.1.00.0902122134500.10279@pacific.mpi-cbg.de>
On Thu, Feb 12, 2009 at 21:37, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So in contrast to the other situation, there are commits left to be > rebased :-)
Ah, I see, funky hack :).
Show 5 quoted lines
>> Also, any comments on the patch? ;) > > There is probably a thinko in it: if "master" already has your patches, > then you cannot apply them on top of "master". That should conflict > rather horribly, and not change the commits that are already upstream.
Hmmm, afaik there are two cases in which 'git rebase' will abort with 'already up to date': 1. onto == current 2. onto == current + some extra patches
A quick demo of 1:
$ git rebase origin/master Current branch master is up to date. $ git rebase -f origin/master Current branch master is up to date, rebase forced. First, rewinding head to replay your work on top of it... Fast-forwarded master to origin/master.
A quick demo of 2:
$ git rebase origin/master Current branch master is up to date. $ git rebase -f origin/master Current branch master is up to date, rebase forced. First, rewinding head to replay your work on top of it... Applying: Do not attempt to render a field if it is disabled Applying: Add ToS agreement to org_admin application related forms. Applying: Added mentor ToS
> Or I misunderstand something here. Quite possible, I am pretty tired.
I hope that's the case, in my manual tests everything worked as expected, but perhaps I didn't understand your concern correctly.
-- Cheers, Sverre Rabbelier