From: Cristian Ciocaltea Date: Tue, 13 Dec 2022 10:37:29 GMT Subject: Re: [RFC PATCH 0/1] rebase --onto detection of already applied commits Message-ID: In-Reply-To: On 12/13/22 02:13, Junio C Hamano wrote: > Cristian Ciocaltea 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