Hello Junio, On Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- 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