On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> wrote: > 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, That's what I meant. > 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 you meant master..foo~10, didn't you ? > and as I said, it has been on my todo list for a long time. If please let me know when you submitting your work, I'm interested to see it. > 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. Can't git figure this out itself ? (I'm not saying the switch is useless) 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