On Thu, 8 Sep 2011, Francis Moreau wrote: > On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk > <martin.von.zweigbergk@xxxxxxxxx> 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 -- 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