On 12/13/22 02:13, Junio C Hamano wrote:
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".
I should have highlighted that 'feature' contains a bunch of commits
that must not be rebased on top of 'new-base', but only the ones in the
'upstream..feature' range need to be considered.
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.
Thanks for clarifying the intended use case of '--onto'. I have wrongly
assumed it could be used as a more flexible rebase alternative, allowing
one to limit the range of commits to be considered for rebasing on top
of a given base, without losing the feature of detecting the already
applied commits.
Currently '--onto' works as if the user provided the
'--reapply-cherry-picks' flag, so maybe a possible improvement of this
patch could be to handle '--no-reapply-cherry-picks' to explicitly
enable the detection.
Would this be an acceptable extension?
Thanks,
Cristian
