Re: git-rebase skips automatically no more needed commits

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Sep 9, 2011, 02:23 UTC
Message-ID: <alpine.DEB.2.00.1109082123300.12564@debian>
In-Reply-To: <CAC9WiBiMYUfaPtrXyW=W7qaZnJqLeFO-B3od7X4u8wUrb8hfUA@mail.gmail.com>

On Thu, 8 Sep 2011, Francis Moreau wrote:

Show 6 quoted lines

> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
> <martin.von.zweigbergk@gmail.com> wrote:
> >
> > Patches that are in both sides of v2.6.39...foo will be filtered, but
> 
> what do you mean by "both sides" ?

See the section called "SPECIFYING RANGES" in "git --help rev-parse". It doesn't define "both sides", but what I mean by that is "both in v2.6.39..foo and in foo..v2.6.39". I believe that section will answer most of the other questions too.

> Yes my use of "git rebase --onto master foo~10 foo"  is equivalent to
> "git rebase master foo, the only difference is that the --onto variant
> allow me to limit the range of commits that I want to rebase. So I
> still want git rebase to do its the filtering process.

Ok, that is different. I think you used v2.6.39 instead of foo~10 previously. Assuming that v2.6.39 is the merge base of foo and master and that foo~10 is a later commit than v2.6.39, you are right that "git rebase --onto master foo~10 foo" could potentially filter out patches already in foo..master, without calculating patch-ids for all commits in master..foo for that matter. I think that would make sense and as I said, it has been on my todo list for a long time. If necessary, we could have a flag to disable the filtering e.g. when the user knows that master is part of a completely separate history from foo.

Martin