Re: git-rebase skips automatically no more needed commits

On Fri, Sep 9, 2011 at 3:06 PM, Martin von Zweigbergk
[off-list ref] wrote:

On Fri, 9 Sep 2011, Francis Moreau wrote:

quoted

On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk
[off-list ref] wrote:

quoted

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 ?

Yes. (I actually did mean "all commits in master..foo", but "_any_
commits in master..foo~10" is more clear and exact.)

quoted

please let me know when you submitting your work, I'm interested to see it.

Will do. It's not really that much work, but I'm not sure when I will
have time for it. If you or anyone else is interested in doing it, you
are of course welcome.

I'm a simple mortal user ;)

quoted

quoted

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)

Yes, but this hypothetical flag would only be to speed things up by
avoid going to the roots to find out that the histories are disjoint.

You're right but in my (mortal) experience, I'm always rebasing
branches onto another one which is not disjoint, so I'm assuming it's
the (very) common case, but I may be wrong. And what I'm assuming is
correct, I think it's make more sense to do the filtering by default
unless the flag tells to do otherwise.

Thanks
-- 
Francis