Re: git-rebase skips automatically no more needed commits

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

On Thu, 8 Sep 2011, Francis Moreau wrote:

> 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