On Thu, Feb 12, 2009 at 21:37, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > So in contrast to the other situation, there are commits left to be > rebased :-) Ah, I see, funky hack :). >> 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 -- 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