Re: git-rebase skips automatically no more needed commits

[Francis Moreau <francis.moro@gmail.com>]

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.
-- 
Francis