Re: [RFC PATCH 0/1] rebase --onto detection of already applied commits

From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Dec 13, 2022, 10:37 UTC
Message-ID: <f4b485c8-3bc4-fb0c-3f7a-084daac7c14d@collabora.com>
In-Reply-To: <xmqqlencqhxy.fsf@gitster.g>

On 12/13/22 02:13, Junio C Hamano wrote:

Show 14 quoted lines

> Cristian Ciocaltea <cristian.ciocaltea@collabora.com> 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.

Show 15 quoted lines

> 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