Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx> writes: > Let's consider the following operation: > > git rebase --onto new-base upstream feature > > where 'feature' contains a few commits on top of 'upstream' which need to be > rebased onto 'new-base'. Isn't it what "git rebase new-base feature" for? "My 'feature' forked from where 'new-base' came from but they updated 'new-base' so I do not know if some of what I had in my 'feature' is in theirs. Please forward port what is still left in 'feature' on top of updated 'new-base' that I just got from them". The primary reason why we have an explicit "--onto" is so that "rebase" is used just like git checkout --detach new-base git cherry-pick upstream..feature git checkout -B feature to deal with a different situation, i.e. "My 'feature' forked from 'upstream', and I have a commit 'new-base'. Just transplant the whole thing on top of it", without having to worry about "what is already in new-base?" at all. After all, 'new-base' may not have ANY ancestry relationship with the 'upstream', so "inspect commits in the range upstream..new-base to exclude those that are the same as the ones in upstream..feature" is not a well defined operation.
