Re: git-rebase skips automatically no more needed commits
- From
- Francis Moreau <francis.moro@gmail.com>
- Date
- Sep 6, 2011, 19:28 UTC
- Message-ID
- <CAC9WiBjrfJeJ854dkJMPwRSwuujRsYLnAd7QX7C_oU8_FdOvQA@mail.gmail.com>
- In-Reply-To
- <7v1uvta97o.fsf@alter.siamese.dyndns.org>
Hello Junio,
On Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> > 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.
Show 5 quoted lines
> > 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