Re: git-rebase skips automatically no more needed commits

> Hello Junio,
> 
> On Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Our assumption has always been that it is a notable event that a patch
>> that does not get filtered with internal "git cherry" (which culls patches
>> that are textually identical to those that are already merged to the
>> history you are rebasing onto) becomes totally unneeded and is safe to ask
>> for human confirmation in the form of "rebase --skip" than to ignore it
>> and give potentially incorrect result silently.
> 
> Ok then I think this "git cherry" filtering is not working in my case
> since it seems to me that commit that I cherry-picked are not
> filtered, please see below.
> 
>>
>> Obviously you do not find it a notable event for some reason. We would
>> need to understand why, and if the reason is sensible, it _might_ make
>> sense to allow a user to say "git rebase --ignore-merged" or something
>> when starting the rebase.
> 
> My use case is the following: I'm maintaining a branch from an
> upstream project (the kernel one). While the upstream project follows
> its development cycle (including some fixes), my branch is stuck. I
> sometime want to includes (or rather backport) some commits that
> happened later in the development cycle. To do that I use "git
> cherry-pick".
> 
> After some period, I'm allowed to rebase to a more recent commit from
> the upstream project and  this rebase 'cancel' the previous 'git
> cherry-pick' I did. But for some reasons, git telling me "nothing
> added to commit ...", which is expected in my case, well I think,
> hence my question.
> 
> Thanks.