On 12/12/22 14:27, Ævar Arnfjörð Bjarmason wrote:
On Mon, Dec 12 2022, Cristian Ciocaltea wrote:When rebase is used with '--onto <newbase>', the patches that might have been already applied on <newbase> are not detected, unless they resolve to an empty commit. When the related files contain additional changes merged, the rebase operation fails due to conflicts that require manual intervention. Ensure the '--onto' variant behaviour is consistent with the common rebase by dropping the already applied commits on the target branch. Note the current behavior is still reachable by using the '--reapply-cherry-picks' flag. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx> --- builtin/rebase.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin/rebase.c b/builtin/rebase.c index b22768ca5b9f..2907c6db5cce 100644 --- a/builtin/rebase.c +++ b/builtin/rebase.c @@ -1659,8 +1659,12 @@ int cmd_rebase(int argc, const char **argv, const char *prefix) strbuf_addstr(&buf, "..."); strbuf_addstr(&buf, branch_name); options.onto_name = xstrdup(buf.buf); - } else if (!options.onto_name) + } else if (!options.onto_name) { options.onto_name = options.upstream_name; + } else if (options.upstream) { + options.restrict_revision = options.upstream; + options.upstream = NULL; + } if (strstr(options.onto_name, "...")) { if (get_oid_mb(options.onto_name, &branch_base) < 0) { if (keep_base)When I apply this & run the tests e.g. t3418 will segfault, and t3403 seems to fail due to the new behavior not having adjusted the test.
Right, a bunch of the merge related tests are now failing, which is one of the reasons I submitted the patch as RFC. If this is not a (totally) wrong solution to the problem, I will try to get all the tests working in a subsequent patch revision.
Which would be my "C" for the "RFC" :) I.e. try to get the tests working, and not segfaulting. If this is a good idea UX wise (I haven't formed an opinion) the main thing that should inform that is having to decide on the various cases that the tests are checking for already. Do I understand this correctly that we'll currently stop and requise a "git rebase --continue" if we have an empty patch with "--onto", but without "--onto" we'll just print a warning, and that you'd like "--onto" to be consistent with the non-onto case?
The main use case I'm trying to address is the one described in the cover letter, mainly to avoid getting conflicts for the already applied commits when the rebase will not result in an empty patch anymore. This would be, indeed, consistent with the non-onto rebase variant.
Currently, "rebase --onto" behaves like "--reapply-cherry-picks" is being enforced, without having the possibility to disable it, which I found rather confusing and not expected.
Thanks for the quick feedback, Cristian
