On Thu, Feb 12, 2009 at 21:37, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
quoted text
> So in contrast to the other situation, there are commits left to be
> rebased :-)

Ah, I see, funky hack :).

quoted text
>> 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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html