From patchwork Thu Mar 13 02:46:36 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elijah Newren X-Patchwork-Id: 14014228 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 446D52D052 for ; Thu, 13 Mar 2025 02:46:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834008; cv=none; b=nvofpdLFOK12dZCRtGgxDVtBxypQKurjTCj+68JRSRpfj0wJGBohWodO+DsokOUoHusa11Zfe+9oj4zTEap+inYBwezcpmHBc/czYD0fjsbftw6CLrInonerlZBzunaB10s0VOl6zB+iY+f0fPVPL94yHW72+T4DzsRV1tQpuyE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834008; c=relaxed/simple; bh=KixAVzaZeeO9Jpi+z7TpEaQV+Y/78zMbUAh4hJpSfHg=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=kdZF+v4OWmxiF+0kk3uHxzQ6dcO/xHZHYO9B5rHcN+AZHO4MPbbDwdLc/NBXjWVn1xJseE239poSn7utQGFFABczTyV89Gs8KrC9YeVCWbJYhQ5lc+EEbIxlmvAgzrETciIWfoQKpNTBtIxWF1zsT6Me6ClBj50RgUDfny7Lmb4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=duAb/fze; arc=none smtp.client-ip=209.85.218.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="duAb/fze" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-ac2ab99e16eso107391266b.0 for ; Wed, 12 Mar 2025 19:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834004; x=1742438804; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=PCmJ/cyxn2mwJiXCaroaRblkEK5hYNzg+tUtuJeFjZs=; b=duAb/fzeWoljaQNl363y1ijlBuu4qTupaQbcRTuUei6Q80J+havkP/lETkf0lwnomy s+dqzjY7gvJljGi0RDxaoSx7J1PEmfcffMjENAbVK0IPFHJHgiAVckXpOS/qOQaHhlef rAE4+XrjWzI/IPsL74nTYtPQRJgQhUJbj2Ylac8oHnngAOY15ou2q8SijjHGU3NcD/DA 91COSZ6Nks3gbGCKP4curHYVerlGllNml7/Qn+HP7/Mc6RnMIbxxGQHySd//U4Qw8Ppi ojlvu9nh7LEVDww2COwQsa8kEXnKqtiA+laTAL/woABYRLhuJAHyT13xdVSd62qwbaWz d5HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834004; x=1742438804; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PCmJ/cyxn2mwJiXCaroaRblkEK5hYNzg+tUtuJeFjZs=; b=fMi2acgJsMZO30HiYvx/AYo1s7WhPszx+7x/jyWBa2IVKV2vH+nlZO3Ypn6V8ULXZT faw75BK4tPZ2rsdp+qfMmdvwB/umnuMOf0wZ1B+92mUi9IPirr4lbjyYbuY5Ma8DhT/p ZZLHsPeuJysMYwFnqWYQb8MJv3mYk3KMW5kfwkgNk3BasfQPWkJc21ascmu9jYHcNjcR Vrd+kpDr5xqFWpp7qMBZmYj27RdFa4rfXeZU2PLHJ31X4wBccBZ7knne1rlRz207wsLJ Laz5cK/cPwGib2J/TrHrZrE7A88AxOfpiVXAcaRTsw8tPTH0nJI7uc50NARKyEatKX/S G3Vw== X-Gm-Message-State: AOJu0YyZCBiJM7FXJCFioQ7EedochMN07DfxcLQ7w8WY61q/eCV7LP8g cRPMGNy6xCMZbk+8bjSxJDAbJUlQTna8nY7neoCrfrkKjAJTxHVMa/la/w== X-Gm-Gg: ASbGncuSBOaR+EFr+Dc/oEqFiXSKduEloPtxcARpuKad4kH6IWabFrG6Zc4uEz/+wG8 NIEF4Ty7pZkfwzLbGdXzwEfSf4Bw1TV2E0HXSo1/eNTJlPFtpE70//JykOfw014KGwUYIaukC42 hLF19UU3uRPrxcAeHl7Cy048YBBkad5bv/8xlSjdow+EevHgx9abhok9Ov+obhHVSmoa6eHAbLt 2OWddU6Za8YYd1Wri9Hy5W1/EjBssPsOiPyT/uvHG5rckMjv8kxPKTEvqEpVhxEPLzBE4oQTTEW UeCDs8vcPPS7f4TKMrJMwGPt+qjikkxdOATisuTjHccWTA== X-Google-Smtp-Source: AGHT+IEH0cpw08WA8dvPfXZKLWk9z1B0LV8cgi7HFGDAC87a5VVDxk/zgJgCBgBr6O+9RqUtRRL65A== X-Received: by 2002:a17:907:74a:b0:ac1:da09:5d32 with SMTP id a640c23a62f3a-ac25274a074mr2832123266b.6.1741834003843; Wed, 12 Mar 2025 19:46:43 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac3149cf133sm21362366b.106.2025.03.12.19.46.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:43 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:36 +0000 Subject: [PATCH v2 1/6] merge-ort: add new merge_ort_generic() function Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Elijah Newren From: Elijah Newren From: Elijah Newren merge-recursive.[ch] have three entry points: * merge_trees() * merge_recursive() * merge_recursive_generic() merge-ort*.[ch] only has equivalents for the first two. Add an equivalent for the final entry point, so we can switch callers to use it and remove merge-recursive.[ch]. While porting it over, finally fix the issue with the label for the ancestor (used when merge.conflictStyle=diff3 as a conflict label). merge-recursive.c has traditionally not allowed callers to set that label, but I have found that problematic for years. (Side note: This function was initially part of the merge-ort rewrite, but reviewers questioned the ancestor label funnyness which I was never really happy with anyway. It resulted in me jettisoning it and hoping at the time that I would eventually be able to force the existing callers to use some other API. That worked with `git stash`, as per 874cf2a60444 (stash: apply stash using 'merge_ort_nonrecursive()', 2022-05-10), but this API is the most reasonable one for `git am` and `git merge-recursive`, if we can just allow them some freedom over the ancestor label.) The merge_recursive_generic() function did not know whether it was being invoked by `git stash`, `git merge-recursive`, or `git am`, and the choice of meaningful ancestor label, when there is a unique ancestor, varies for these different callers: * git am: ancestor is a constructed "fake ancestor" that user knows nothing about and has no access to. (And is different than the normal thing we mean by a "virtual merge base" which is the merging of merge bases.) * git merge-recursive: ancestor might be a tree, but at least it was one specified by the user (if they invoked merge-recursive directly) * git stash: ancestor was the commit serving as the stash base Thus, using a label like "constructed merge base" (as merge_recursive_generic() does) presupposes that `git am` is the only caller; it is incorrect for other callers. This label has thrown me off more than once. Allow the caller to override when there is a unique merge base. Signed-off-by: Elijah Newren --- merge-ort-wrappers.c | 64 ++++++++++++++++++++++++++++++++++++++++++++ merge-ort-wrappers.h | 12 +++++++++ merge-ort.c | 17 ++++++++---- merge-ort.h | 5 ++++ 4 files changed, 93 insertions(+), 5 deletions(-) diff --git a/merge-ort-wrappers.c b/merge-ort-wrappers.c index d6f61359965..62834c30e9e 100644 --- a/merge-ort-wrappers.c +++ b/merge-ort-wrappers.c @@ -1,9 +1,13 @@ #include "git-compat-util.h" #include "gettext.h" #include "hash.h" +#include "hex.h" +#include "lockfile.h" #include "merge-ort.h" #include "merge-ort-wrappers.h" #include "read-cache-ll.h" +#include "repository.h" +#include "tag.h" #include "tree.h" #include "commit.h" @@ -64,3 +68,63 @@ int merge_ort_recursive(struct merge_options *opt, return tmp.clean; } + +static struct commit *get_ref(struct repository *repo, + const struct object_id *oid, + const char *name) +{ + struct object *object; + + object = deref_tag(repo, parse_object(repo, oid), + name, strlen(name)); + if (!object) + return NULL; + if (object->type == OBJ_TREE) + return make_virtual_commit(repo, (struct tree*)object, name); + if (object->type != OBJ_COMMIT) + return NULL; + if (repo_parse_commit(repo, (struct commit *)object)) + return NULL; + return (struct commit *)object; +} + +int merge_ort_generic(struct merge_options *opt, + const struct object_id *head, + const struct object_id *merge, + int num_merge_bases, + const struct object_id *merge_bases, + struct commit **result) +{ + int clean; + struct lock_file lock = LOCK_INIT; + struct commit *head_commit = get_ref(opt->repo, head, opt->branch1); + struct commit *next_commit = get_ref(opt->repo, merge, opt->branch2); + struct commit_list *ca = NULL; + + if (merge_bases) { + int i; + for (i = 0; i < num_merge_bases; ++i) { + struct commit *base; + if (!(base = get_ref(opt->repo, &merge_bases[i], + oid_to_hex(&merge_bases[i])))) + return error(_("Could not parse object '%s'"), + oid_to_hex(&merge_bases[i])); + commit_list_insert(base, &ca); + } + } + + repo_hold_locked_index(opt->repo, &lock, LOCK_DIE_ON_ERROR); + clean = merge_ort_recursive(opt, head_commit, next_commit, ca, + result); + free_commit_list(ca); + if (clean < 0) { + rollback_lock_file(&lock); + return clean; + } + + if (write_locked_index(opt->repo->index, &lock, + COMMIT_LOCK | SKIP_IF_UNCHANGED)) + return error(_("Unable to write index.")); + + return clean ? 0 : 1; +} diff --git a/merge-ort-wrappers.h b/merge-ort-wrappers.h index 90af1f69c55..aeffa1c87b4 100644 --- a/merge-ort-wrappers.h +++ b/merge-ort-wrappers.h @@ -22,4 +22,16 @@ int merge_ort_recursive(struct merge_options *opt, const struct commit_list *ancestors, struct commit **result); +/* + * rename-detecting three-way merge. num_merge_bases must be at least 1. + * Recursive ancestor consolidation will be performed if num_merge_bases > 1. + * Wrapper mimicking the old merge_recursive_generic() function. + */ +int merge_ort_generic(struct merge_options *opt, + const struct object_id *head, + const struct object_id *merge, + int num_merge_bases, + const struct object_id *merge_bases, + struct commit **result); + #endif diff --git a/merge-ort.c b/merge-ort.c index 46e78c3ffa6..b4ff24403a1 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -4878,9 +4878,9 @@ static inline void set_commit_tree(struct commit *c, struct tree *t) c->maybe_tree = t; } -static struct commit *make_virtual_commit(struct repository *repo, - struct tree *tree, - const char *comment) +struct commit *make_virtual_commit(struct repository *repo, + struct tree *tree, + const char *comment) { struct commit *commit = alloc_commit_node(repo); @@ -5186,6 +5186,8 @@ static void merge_ort_internal(struct merge_options *opt, ancestor_name = "empty tree"; } else if (merge_bases) { ancestor_name = "merged common ancestors"; + } else if (opt->ancestor) { + ancestor_name = opt->ancestor; } else { strbuf_add_unique_abbrev(&merge_base_abbrev, &merged_merge_bases->object.oid, @@ -5275,8 +5277,13 @@ void merge_incore_recursive(struct merge_options *opt, { trace2_region_enter("merge", "incore_recursive", opt->repo); - /* We set the ancestor label based on the merge_bases */ - assert(opt->ancestor == NULL); + /* + * We set the ancestor label based on the merge_bases...but we + * allow one exception through so that builtin/am can override + * with its constructed fake ancestor. + */ + assert(opt->ancestor == NULL || + (merge_bases && !merge_bases->next)); trace2_region_enter("merge", "merge_start", opt->repo); merge_start(opt, result); diff --git a/merge-ort.h b/merge-ort.h index 82f2b3222d2..b63bc5424e7 100644 --- a/merge-ort.h +++ b/merge-ort.h @@ -44,6 +44,11 @@ struct merge_result { unsigned _properly_initialized; }; +/* Mostly internal function also used by merge-ort-wrappers.c */ +struct commit *make_virtual_commit(struct repository *repo, + struct tree *tree, + const char *comment); + /* * rename-detecting three-way merge with recursive ancestor consolidation. * working tree and index are untouched. From patchwork Thu Mar 13 02:46:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elijah Newren X-Patchwork-Id: 14014230 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C1253E47B for ; Thu, 13 Mar 2025 02:46:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834009; cv=none; b=b1DbZ3CqBziyYYN8Fbc9ngF4wk2GJ6SSK303eJE3BgG0i7X3gr3XCVkTjo/kD8X4M7UGtq95grN4nDUs0Q0Jfurxz9kRS2s/jAsl5TOk1G5MQMTa6erIMgZm859gWVDrXIf0MhayaXgCFz/p0CdBSfGJGBhZ8NSnkppm1MNYO8Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834009; c=relaxed/simple; bh=xUVipBK2XPdMX30YWSax2RLZ6B5D9ibh5UAtGaMztOc=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=rwWVU04dzIiDxIjXS1mm+vtXgMeWy5xWTVW8gU5JWtNnlkngIXQuTgmOFeIp21wt8Wp0RT3qhQvbSsC5dVMbQU8pPGt7XnAIAo4veNrlloJfKuTELVL4O4S5mrdxTu1rZLb/rUJACA86sGxeJKkwi2sIhQOaAa9yVu02dWXlIWI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YQ6uhNKT; arc=none smtp.client-ip=209.85.208.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YQ6uhNKT" Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5e5bc066283so630535a12.0 for ; Wed, 12 Mar 2025 19:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834005; x=1742438805; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=ANoKBSevl9EaOIVeKcMUvTLHONcyDDRY7s+8bIlu/uI=; b=YQ6uhNKTCxHh/P1bVPfE4cmHx/juxM/asjioMGt5sR2JeoHO7/k4hAG4mIGYbuSeIS 9Eiyp7IsDcug11NQICG5E23RqEe3yuHF8LS9GMFzyeGq0GmLiJF1RY15ZcS/TNnIc0AK bjAWS2OIgm9wR1slahcGeSn7owIzsSASTG8EqaiJBgmKEnm2wpHr4biLMdWfAKxSryVw zRlehonZmcU+D+WFB/JCi/+fVLDUVzFLUuJyFaVDNBeeaWmKttcsSle+EjSgacMNHg/M lVuHSAS9LYCjzP4SIlFxTQVrrzHhROy19tTOW6zL+/vNhqV4oyDwimAP1ekWfCAX15+O Kdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834005; x=1742438805; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ANoKBSevl9EaOIVeKcMUvTLHONcyDDRY7s+8bIlu/uI=; b=rYTOrGk2Nu3Ene2lNj2ddz3aZFwgFIbdVTJZ/YgolqkO6GVie8ckFbdwr0HhE05plz wwnbY3Rnoz0eMbU45Vt115TQ0CU9jc0IlhVu6rcKVwujGdViwEfRiF2UoaSGqAF/zNlG mVIsng05e/UEAsGYCYzfEAvY6ks0sB/KCL52iVhHgzaq9RVb8wDWAMpnYd97eQfGDJCQ MdbXyde/VGwKgYFZOtQaim3IP7uFpkPTQlN3SFR21PZ6Sxs3WY5yVoALLx4ZJaO6tLIo yfOd1QXF6y0I7iC1YIpXRA0S7olyvc2h4jQ1LZ10VIcPMAeaEfz13SG3fJ4eeix88T+r E75g== X-Gm-Message-State: AOJu0YxCquJCt/yy5SrRhDO6yxNeG6b23lLYyjQKtV0WULGy2kMHG6P0 ZoreLSDqlaoDDDHuuJTFKL+z9CkfiGWaIesLOIM9e4wsyvzn93t/4kpAcQ== X-Gm-Gg: ASbGncvoFdB9l+XdWvf8MCguc9ls5OzhIK9u3gkKtbKWTgtQTeBJiC3ScAyb8dk+HgJ CmPVNOBW6lhW0WGCK9oJsCfuPVHgjYvQYNK+auTWCmGArLjoyJVsGX6VhK6bQPJfkr/Qr7xClPz 2zIoPbyynQr+Go9swOYIuSVG/QrAUzyIGYFrGS5eT5D4D28I/zAN+vLno7qC2ZLEGa7cQulHgaL wdYuD/BQEFvYib8/Zoy75y4KwDIuj6OeX2AVQEqETqDLQ5QFRtUu3pQO6ZpB8w4Ybt5Nme2MA9c FrEpb1lCdiae2k4lkOUhH0DqPIl7ILauncZ/1HFMimlzH+nrPDb7SUOv X-Google-Smtp-Source: AGHT+IFhkKwBRmeHtn5Hh0ujJKlujp/HwoNJ93MlgS2bS78A/Zx98LxMOo1t+UfO1VqrYwd2BKr6xA== X-Received: by 2002:a17:907:9492:b0:ac2:d5c6:43ad with SMTP id a640c23a62f3a-ac2d5c64c0dmr787890866b.30.1741834004620; Wed, 12 Mar 2025 19:46:44 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac314a9bcf3sm20780966b.162.2025.03.12.19.46.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:44 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:37 +0000 Subject: [PATCH v2 2/6] merge-ort: allow rename detection to be disabled Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Elijah Newren From: Elijah Newren From: Elijah Newren When merge-ort was written, I did not at first allow rename detection to be disabled, because I suspected that most folks disabling rename detection were doing so solely for performance reasons. Since I put a lot of working into providing dramatic speedups for rename detection performance as used by the merge machinery, I wanted to know if there were still real world repositories where rename detection was problematic from a performance perspective. We have had years now to collect such information, and while we never received one, waiting longer with the option disabled seems unlikely to help surface such issues at this point. Also, there has been at least one request to allow rename detection to be disabled for behavioral rather than performance reasons (see the thread including https://lore.kernel.org/git/CABPp-BG-Nx6SCxxkGXn_Fwd2wseifMFND8eddvWxiZVZk0zRaA@mail.gmail.com/ ), so let's start heeding the config and command line settings. Signed-off-by: Elijah Newren --- Documentation/merge-strategies.adoc | 12 ++++++------ merge-ort.c | 5 +++++ t/t4301-merge-tree-write-tree.sh | 6 ++++++ 3 files changed, 17 insertions(+), 6 deletions(-) diff --git a/Documentation/merge-strategies.adoc b/Documentation/merge-strategies.adoc index 93822ebc4e8..59f5ae36ccb 100644 --- a/Documentation/merge-strategies.adoc +++ b/Documentation/merge-strategies.adoc @@ -82,6 +82,11 @@ find-renames[=];; rename-threshold=;; Deprecated synonym for `find-renames=`. +no-renames;; + Turn off rename detection. This overrides the `merge.renames` + configuration variable. + See also linkgit:git-diff[1] `--no-renames`. + subtree[=];; This option is a more advanced form of 'subtree' strategy, where the strategy makes a guess on how two trees must be shifted to @@ -107,7 +112,7 @@ For a path that is a submodule, the same caution as 'ort' applies to this strategy. + The 'recursive' strategy takes the same options as 'ort'. However, -there are three additional options that 'ort' ignores (not documented +there are two additional options that 'ort' ignores (not documented above) that are potentially useful with the 'recursive' strategy: patience;; @@ -121,11 +126,6 @@ diff-algorithm=[patience|minimal|histogram|myers];; specifically uses `diff-algorithm=histogram`, while `recursive` defaults to the `diff.algorithm` config setting. -no-renames;; - Turn off rename detection. This overrides the `merge.renames` - configuration variable. - See also linkgit:git-diff[1] `--no-renames`. - resolve:: This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge diff --git a/merge-ort.c b/merge-ort.c index b4ff24403a1..1d3b690224e 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -3448,6 +3448,11 @@ static int detect_and_process_renames(struct merge_options *opt) if (!possible_renames(renames)) goto cleanup; + if (!opt->detect_renames) { + renames->redo_after_renames = 0; + renames->cached_pairs_valid_side = 0; + goto cleanup; + } trace2_region_enter("merge", "regular renames", opt->repo); detection_run |= detect_regular_renames(opt, MERGE_SIDE1); diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh index eea19907b55..44f7d077593 100755 --- a/t/t4301-merge-tree-write-tree.sh +++ b/t/t4301-merge-tree-write-tree.sh @@ -73,6 +73,12 @@ test_expect_success 'Clean merge' ' test_cmp expect actual ' +# Repeat the previous test, but turn off rename detection +test_expect_success 'Failed merge without rename detection' ' + test_must_fail git -c diff.renames=false merge-tree --write-tree side1 side3 >out && + grep "CONFLICT (modify/delete): numbers deleted" out +' + test_expect_success 'Content merge and a few conflicts' ' git checkout side1^0 && test_must_fail git merge side2 && From patchwork Thu Mar 13 02:46:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elijah Newren X-Patchwork-Id: 14014229 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9401F5FB95 for ; Thu, 13 Mar 2025 02:46:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834009; cv=none; b=kBQVBQMCkHp6uGLoG0aYDaxYCmqnp7zAdPzAo9y4yiIV5uB3eN9C2DGviy8GfJW4FOmyK/8TeBaQxpN/X/lNv25807lEz0eXkM9HOtFatDMX5OUBb3hyYF+fjTrBMfudbwotrAWxAuJV8ANMaHz30UsL6AJl6R9RDwnsTMom1hs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834009; c=relaxed/simple; bh=/l7IKIFHKD+XCI8QjZ/6r8ALTma3Z5f46t+dZNPiITo=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=czyZkv8ZcvNDDd75NuetvJyGOkmmwCYvUFQl2Zm/TLy6rfK4GDgLdtgcnc68934YUg5E02C1mbx9NU53OGqtEPhBjS61NUMx3meyCGyWFYB1l7YCSk31eqpDFvAnGik+88K7ClrhL7JvJWKPnKTE0rkliH59mv/3HADBPm8A7As= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mrcMj2rQ; arc=none smtp.client-ip=209.85.218.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mrcMj2rQ" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-ac2ab99e16eso107395466b.0 for ; Wed, 12 Mar 2025 19:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834005; x=1742438805; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=6J/vEF1OqVfBsM3dhURjp4SRf5MgIYMEoobbdf3odIM=; b=mrcMj2rQlndEzxuI6UFUN2+YHYZZpcBBV3RMYiQTpWhAly6tQQnFy9K6Z5IP4IRg0w 9Dj3h9GbNOWIkt9ZR0yyjKkrsX6Yajs3IqZINOAL2eoJvNVXk/mtdfUaS/Gaidfqil+4 f4n4Gk47nl+rkp/FXdcpMEIDNoqOZuGM9w3Q0PAwomg6rcrPIIXMRAyllsCA9Yet+Op4 vqeU6ryX18jaD1lweiNPKlL6XzyAqYEwr2deqnMbQ8ZNjSRGYc8q0HnBY7fTkQmGkcf6 qYQJ/aUblTkmvOw0YLiGzOVG7TSC4koCh9lvG856ru7Hnq8w8CRAhy1kgn99YAXZIIJp zcBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834005; x=1742438805; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6J/vEF1OqVfBsM3dhURjp4SRf5MgIYMEoobbdf3odIM=; b=IiW5FzqNmoeHLp92hVO/VckgoaCOy66nDwfQ7/X5im6VFJ6kdG6rH1pjP1V4wtyCZn fDqeJYAIVYYbWFwPjapeyFKoYOz7YpTCiwOY069AmFKqL1AuEbnCeOGTNpLpNI071GOu ImHbYIUEkzfSy/Qfkpj0skkXEPZaPNvxvdlX5AQP1GZFbjYELg1Dep/orapZ9NW/GSkr j4SMGWwMLV36Mzd/yo9+r5AorUcw0ljuf2vaer7bG3K/Yx5zT5hbWUfz93dmIgA7Gxhx I0hzP0eT+6hoyBEQhp4suzDUp6Q7EFffvbNJDlD5Wf6NbhR/wDPob4QeLzLHDeAvcocC Kvpw== X-Gm-Message-State: AOJu0YwFn6fzh05lxYaatlts4Tw5bGuEerLHsAwCNSM9j8qjHOG7NSlm YfcmAadaE8TVaEjcnuN8j8wO4SEC1JbslWHpGj+xjjyIfDWT9vBI8B8bmw== X-Gm-Gg: ASbGnctw7GySnd79TI5+3FxSxxz+xl0eL8IrSIaousUhIkBFywccahcOFIroZzqG9DH rzrkMiJRJKKbORWtCwhyhesT60k9AcjbTEDoGvPdFvSB3IrRi9A9lYyXMelb7a8U28VclOopjF5 b8dxAMApSbMe66D59p911JwciDekQ9yz6++rL7w3sqmoYToxCEzPuRlcSswdhc/Tg1SE1/Jsdfz eJhVMh/AUgwXnYeDcTbgcuBTW0ZneDCvht8UQInXTvMGXI2mgk3v04fOl6xZo9P7XmlPBtoTVxF m/1/UXGWLWVKNYdLkKvp0002fHgEmMlR62dk13UcfvFsgg== X-Google-Smtp-Source: AGHT+IHdX5fpFDRMtQME6fConWjX9J1XPNrB1rSYMzVugh2vanzriBntRYcsjYzRPOeoLNFiu+hdOg== X-Received: by 2002:a17:906:dd1:b0:ac2:6bb5:413c with SMTP id a640c23a62f3a-ac26bb54220mr2136123866b.31.1741834005258; Wed, 12 Mar 2025 19:46:45 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac314aa4b67sm21193266b.172.2025.03.12.19.46.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:44 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:38 +0000 Subject: [PATCH v2 3/6] merge-ort: support having merge verbosity be set to 0 Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Elijah Newren From: Elijah Newren From: Elijah Newren Various callers such as am & checkout set the merge verbosity to 0 to avoid having conflict messages printed. While this could be achieved by avoiding the wrappers from merge-ort-wrappers and instead passing 0 for display_update_msgs to merge_switch_to_result(), for simplicity of converting callers simply allow them to also achieve this with the merge-ort-wrappers by setting verbosity to 0. Signed-off-by: Elijah Newren --- merge-ort-wrappers.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/merge-ort-wrappers.c b/merge-ort-wrappers.c index 62834c30e9e..c54d56b3446 100644 --- a/merge-ort-wrappers.c +++ b/merge-ort-wrappers.c @@ -33,6 +33,7 @@ int merge_ort_nonrecursive(struct merge_options *opt, struct tree *merge_base) { struct merge_result result; + int show_msgs; if (unclean(opt, head)) return -1; @@ -42,9 +43,10 @@ int merge_ort_nonrecursive(struct merge_options *opt, return 1; } + show_msgs = !!opt->verbosity; memset(&result, 0, sizeof(result)); merge_incore_nonrecursive(opt, merge_base, head, merge, &result); - merge_switch_to_result(opt, head, &result, 1, 1); + merge_switch_to_result(opt, head, &result, 1, show_msgs); return result.clean; } @@ -57,13 +59,15 @@ int merge_ort_recursive(struct merge_options *opt, { struct tree *head = repo_get_commit_tree(opt->repo, side1); struct merge_result tmp; + int show_msgs; if (unclean(opt, head)) return -1; + show_msgs = !!opt->verbosity; memset(&tmp, 0, sizeof(tmp)); merge_incore_recursive(opt, merge_bases, side1, side2, &tmp); - merge_switch_to_result(opt, head, &tmp, 1, 1); + merge_switch_to_result(opt, head, &tmp, 1, show_msgs); *result = NULL; return tmp.clean; From patchwork Thu Mar 13 02:46:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Schindelin X-Patchwork-Id: 14014231 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCE31137923 for ; Thu, 13 Mar 2025 02:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834010; cv=none; b=eX/mspYosVUMN7nc7sz704NOpVzCKIh9TPa6ZNEUy16TNfdBMQXZji0JrtuwCL6qbrzgVYjPVCKCwFLtn7SYeOre7gXmQf2C2pSW4Wp6ZzTKYehJxQwwNliKCFdjZi1gHCfhNFs/U93X1o/ySqGnq9qwkYkT9xXKEP+sCorzTxk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834010; c=relaxed/simple; bh=nsGHKNcDtwMBPgznnsaZ6t0adM5uk30DmWL9oAlw3YU=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=k1YCBUURYhdem2BEGPH7rqHMGEaGYHEdnTIp7l9JXn/zImq4+BAb+NpNFmsOXk3yZ0S2Xu56P8Fot5sQHG9EYB4ITtwqsNxyBnMGSdzoYmWb9xUPfFrlUREnRp5sOcscNf6camxtW5VdfdNdCLMwPGhDHcPKW6cven+fRe97gBk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AfZfzjWi; arc=none smtp.client-ip=209.85.218.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AfZfzjWi" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-ac25313ea37so102224066b.1 for ; Wed, 12 Mar 2025 19:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834007; x=1742438807; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=sojw9SiGz0+X+51vZnmynJtCVIS+mCImu6MKlhc0lCI=; b=AfZfzjWiF4X1yu1aXwPRQJnYgK91GWKwH+e/1AV3xJr4GVSbEy9Z+WLVIPh4jPm+DU jd996LHkDEW+fbMtG/XILUszo+QAaYGvywZ5bEtMioqxWYntnYgauUc6AsOi2+tziKs2 h7hBAAN75jvrh8bgTaJ32u9tTey45j69Md6JcdDjTP+haONAdepXZzpdejKEh98eMT4x BHpKniu/+KZP7Cgdl978Ov685vTFNyemJfffrtU0Kf4qhv4PWnWHM7uds8mGFoV8+HY+ My9Rsds4b777pQaBAF1bLdJO7y5bRMYF8uyBdKWFnDSWATJAAa8bIy9EtuEostwP86Cc g/sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834007; x=1742438807; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sojw9SiGz0+X+51vZnmynJtCVIS+mCImu6MKlhc0lCI=; b=PfEyN/r2xXdDKHOKoih7fe95786TSkDLn3IX7NxbdsIsNQqovU6DGOS2QCOEmO2ihX tDROwrm8faxgQNOzVzAx/r+8LZfNlF+2zEtOSESJSiPXTotkorYsbkyvK2w44uRceHZ8 enX39gGwdpPo/ym97Ldc0ml66SnBPyieISPjvJnJRn8wvIWykazoPZCJvyHxQWCJSlLM CYei0qomDp2FTmR0rayl82vkzBFEFYp171eMTFwOdXkZjiz9xcsqaCqj3vepc0PFJrbW vBZrdlWn9ReoJEUluUjYJkJil37fdaacorfWG+DywVQYVMjXQyqjxhtCKD4SbFw3oMPv JuUQ== X-Gm-Message-State: AOJu0Yyr225CnlYz5Kklap9Mpw7yToiRVdod7bWoe2A7EHMHnVdx+m5E TttIb48WjKQRnCPCLA023mkioPN/2mtI1zOj3TKRfaXTKhrzwwvYsKrrdw== X-Gm-Gg: ASbGnctNcLrp6wfJl5IQAANMGRIfDJYaqmXlcTy4Igz1FWWsHJ2Kh5wuo+RMkfFx52I wC5vRU3ElyZJesUqQCa+NLIUoBXFYRqCRZUXARLrEoT1sV8E+IWsIscWcvtiF0JhSAu0iX76/CI UZY5p9k7h0hyxtdtJQnTx0ExTj5QyaQnwKJF/gGUaflcScnhf9AFj4BuE2/ISLG2wCaNy27EAdW J+rYNZaghPW32eIU8UGQCjrITbdplSeiw+y4e2EehNwRBh2SQasJwkEbBaH0bPqUXKB9bBMrzJQ m1eaKqci6d1Nmk46TVipXnacKuT2UI+aUiOgwLCTyymJkUNtzZQ9bzch X-Google-Smtp-Source: AGHT+IGAbvzGh+lELnMVHcEqxTrX7F4B0HRwXe7CEUKkPOqdX88n2cAzVDsDDil3qu/03ulHOn3cjA== X-Received: by 2002:a17:907:86a7:b0:ac2:d55b:c35a with SMTP id a640c23a62f3a-ac2d55bcb69mr822903166b.47.1741834006450; Wed, 12 Mar 2025 19:46:46 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac3149cf22dsm20827866b.111.2025.03.12.19.46.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:45 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:39 +0000 Subject: [PATCH v2 4/6] t3650: document bug when directory renames are turned off Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Johannes Schindelin From: Johannes Schindelin From: Johannes Schindelin There is a bug in the way renames are cached that rears its head when `merge.directoryRenames` is set to false; it results in the following message: merge-ort.c:3002: process_renames: Assertion `newinfo && !newinfo->merged.clean' failed. Aborted It is quite a curious bug: the same test case will succeed, without any assertion, if instead run with `merge.directoryRenames=true`. Further, the assertion does not manifest while replaying the first commit, it manifests while replaying the _second_ commit of the commit range. But it does _not_ manifest when the second commit is replayed individually. This would indicate that there is an incomplete rename cache left-over from the first replayed commit which is being reused for the second commit, and if directory rename detection is enabled, the missing paths are somehow regenerated. Incidentally, the same bug can by triggered by modifying t6429 to switch from merge.directoryRenames=true to merge.directoryRenames=false. Signed-off-by: Johannes Schindelin [en: tweaked the commit message slightly, including adjusting the line number of the assertion to the latest version, and the much later discovery that a simple t6429 tweak would also display the issue.] Signed-off-by: Elijah Newren --- t/t3650-replay-basics.sh | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh index 389670262e4..cade7930765 100755 --- a/t/t3650-replay-basics.sh +++ b/t/t3650-replay-basics.sh @@ -195,4 +195,26 @@ test_expect_success 'using replay on bare repo to rebase multiple divergent bran done ' +test_expect_failure 'merge.directoryRenames=false' ' + # create a test case that stress-tests the rename caching + git switch -c rename-onto && + + mkdir -p to-rename && + test_commit to-rename/move && + + mkdir -p renamed-directory && + git mv to-rename/move* renamed-directory/ && + test_tick && + git commit -m renamed-directory && + + git switch -c rename-from HEAD^ && + test_commit to-rename/add-a-file && + echo modified >to-rename/add-a-file.t && + test_tick && + git commit -m modified to-rename/add-a-file.t && + + git -c merge.directoryRenames=false replay \ + --onto rename-onto rename-onto..rename-from +' + test_done From patchwork Thu Mar 13 02:46:40 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elijah Newren X-Patchwork-Id: 14014232 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84BF313AA2F for ; Thu, 13 Mar 2025 02:46:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834011; cv=none; b=H+f4nbjsENMIbd4ULLHOCTozr1qtcuNdPeRdQVOdyXDqirS6OIIi0WJUkhnxByV/Gw+1fqjseGmZ5VCea00NZ991nwCewpZhyp3STe0IdC55SRea3bqlrZmporOZ2d2aidXQTGl08YBFXf2IBvnlehBCeNImgyOklO0VOAYd0kY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834011; c=relaxed/simple; bh=L8aYXlsgYTW7r0VUZck+pVqsskBcy7fRBD70ndGtQJU=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=DmCgWnZ0wWIWq6bfVYGIycteiClCbbPfN1hoEbUjg1vrjeTxhu9LyCwJRHGNPyWIKsnXKBFDJy6sD23S0B7qISj/Bto0V6a5K5cnzqhmkHUvMl7gtnCSC2LedJMwlBiBaRGDWA7tRuL8OAZ6NRrD+o1sVSxMXsrvwRKzrat3ugw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZLLilTFz; arc=none smtp.client-ip=209.85.218.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZLLilTFz" Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-aaec61d0f65so93946766b.1 for ; Wed, 12 Mar 2025 19:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834007; x=1742438807; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=V+8si5HEFRgzN0jnJVYf2WA7bOvtvq/Eb8yK4PadRuU=; b=ZLLilTFzkqQXrUQH4qnV1tSZfg1mRdATk+abIbqDuTrZ2iRCGouR5PlKvdLlRr7H1B 1JGbeSCM6nLGa+MGR+XAFTyD6q122s/KnCWyLzfDZIUw9Tts+G+SjwFFjpqN6ZE4NeTn xOyT/L/cpvJvvOvOPDDCuYwX2ihINAt/AuIw62arIERUQYFwfB+MyzTzt0lFOwjBYWC6 BoimY+GpEli+uhUfqmkL8kdT08Ycdc6qAQT0bT2tFk8My7hbhzxnLmoSGYi3EWhw7tMB wYysv4M5wlSVC7U4iXfrjk8Imd2AY/4zVgvUaUOjTezbjMH6pGZkENGMxkA17GKPIXI4 mF4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834007; x=1742438807; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V+8si5HEFRgzN0jnJVYf2WA7bOvtvq/Eb8yK4PadRuU=; b=Tg6Caq2k5HWxipj+eg/pGyc/ZyiE4bts7tBcVK/gDNIOHG9i1G6kvQWPRb7Wv2/6YD QwkIfyWaORhoFk9C/aLbEWMfwbH+yUrpyubg7JWebRQyh9T0STknNRHflBMioLiR6c1F 0HOxRoDR2oBzvTLvAQPgnjJDoEr6C/AM8eX4rm0cq6WSVLE2EHgqX4OIVybZdHvA6eyP Ogxf6xwDbfr2/xu6KzjD61qhEx+7EvGoaaK0dkdoq0rvFumfC0DiR+6Hhbt70Ut/TDIr A/QIPMKZfezB0HqF6YuIMeBFN8irom+NwehmOHHW1NLeBt8ywFtz/ZxIZSWTdOORQSi/ o+5Q== X-Gm-Message-State: AOJu0YzaMC0J0u+u2YoREQ7WtEIB19CuQPT6LWWOYxU6WlH7wIF2EoTj uB3nLwFUSFGPfvfsMxk+r82JbEjJawq36hEs6qBDYRzcZ7WZFageRDexBQ== X-Gm-Gg: ASbGncvDR4qzeJR6ah1CSW/knXO+EZsTY4QnQ/lPOlNsA2dWryexSav6HM4mmE3W48N ZJOeAR7xvgnp2YN8IJ18/xyxq27jhaOYqs57/KerGlNUFzK9VdwtXxw4Kzuzz0y3SEDWIAFKmSA 9RmsCYBpLLct7W7YCVIFiJ/fLXvAa1Gqca+ERcbQ7khlEAbrRhidt7I7qUICSLvFtNm8J3a1Wra 28MfWXm5arVpxw+/L3HjEKXAqUA4lOMvlhQfTjcoEbC/JotqizD13Qy7dIFptuZ8AqQHQ/UkX0Z NhsabP0Z69KNS/UjVHuUUK/lzVxZAujjSjnUfJa4myGY+A== X-Google-Smtp-Source: AGHT+IF4tbNdDtEH8wCqKbRAWX0ld05j76MojRqm+OJilDea37Q/QZm9202w5wssof/ZoW5OXHqoRw== X-Received: by 2002:a17:907:c302:b0:ac2:f93:b7c5 with SMTP id a640c23a62f3a-ac2526e1ba9mr2677493066b.31.1741834007171; Wed, 12 Mar 2025 19:46:47 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac314a3a31csm20949266b.127.2025.03.12.19.46.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:46 -0700 (PDT) Message-Id: In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:40 +0000 Subject: [PATCH v2 5/6] merge-ort: fix merge.directoryRenames=false Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Elijah Newren From: Elijah Newren From: Elijah Newren There are two issues here. First, when merge.directoryRenames is set to false, there are a few code paths that should be turned off. I missed one; collect_renames() was still doing some directory rename detection logic unconditionally. It ended up not having much effect because get_provisional_directory_renames() was skipped earlier and not setting up renames->dir_renames, but the code should still be skipped. Second, the larger issue is that sometimes we get a cached_pair rename from a previous commit being replayed mapping A->B, but in a subsequent commit but collect_merge_info() doesn't even recurse into the directory containing B because there are no source pairings for that rename that are relevant; we can merge that commit fine without knowing the rename. But since the cached renames are added to the normal renames, when we go to process it and find that B is not part of opt->priv->paths, we hit the assertion error process_renames: Assertion `newinfo && ~newinfo->merged.clean` failed. I think we could fix this at the beginning of detect_regular_renames() by pruning from cached_pairs any entry whose destination isn't in opt->priv->paths, but it's suboptimal in that we'd kind of like the cached_pair to be restored afterwards so that it can help the subsequent commit, but more importantly since it sits at the intersection of the caching renames optimization and the relevant renames optimization, and the trivial directory resolution optimization, and I don't currently have Documentation/technical/remembering-renames.txt fully paged in, I'm not sure if that's a full solution or a bandaid for the current testcase. However, since the remembering renames optimization was the weakest of the set, and the optimization is far less important when directory rename detection is off (as that implies far fewer potential renames), let's just use a bigger hammer to ensure this special case is fixed: turn off the rename caching. We do the same thing already when we encounter rename/rename(1to1) cases (as per `git grep -3 disabling.the.optimization`, though it uses a slightly different triggering mechanism since it's trying to affect the next time that merge_check_renames_reusable() is called), and I think it makes sense to do the same here. Signed-off-by: Elijah Newren --- merge-ort.c | 31 +++++++++++++++++++++++++++++-- t/t3650-replay-basics.sh | 2 +- 2 files changed, 30 insertions(+), 3 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index 1d3b690224e..785e5c6f24a 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -3404,6 +3404,11 @@ static int collect_renames(struct merge_options *opt, pool_diff_free_filepair(&opt->priv->pool, p); continue; } + if (opt->detect_directory_renames == MERGE_DIRECTORY_RENAMES_NONE && + p->status == 'R' && 1) { + possibly_cache_new_pair(renames, p, side_index, NULL); + goto skip_directory_renames; + } new_path = check_for_directory_rename(opt, p->two->path, side_index, @@ -3421,6 +3426,7 @@ static int collect_renames(struct merge_options *opt, if (new_path) apply_directory_rename_modifications(opt, p, new_path); +skip_directory_renames: /* * p->score comes back from diffcore_rename_extended() with * the similarity of the renamed file. The similarity is @@ -5025,7 +5031,8 @@ static void merge_start(struct merge_options *opt, struct merge_result *result) trace2_region_leave("merge", "allocate/init", opt->repo); } -static void merge_check_renames_reusable(struct merge_result *result, +static void merge_check_renames_reusable(struct merge_options *opt, + struct merge_result *result, struct tree *merge_base, struct tree *side1, struct tree *side2) @@ -5050,6 +5057,26 @@ static void merge_check_renames_reusable(struct merge_result *result, return; } + /* + * Avoid using cached renames when directory rename detection is + * turned off. Cached renames are far less important in that case, + * and they lead to testcases with an interesting intersection of + * effects from relevant renames optimization, trivial directory + * resolution optimization, and cached renames all converging when + * the target of a cached rename is in a directory that + * collect_merge_info() does not recurse into. To avoid such + * problems, simply disable cached renames for this case (similar + * to the rename/rename(1to1) case; see the "disabling the + * optimization" comment near that case). + * + * This could be revisited in the future; see the commit message + * where this comment was added for some possible pointers. + */ + if (opt->detect_directory_renames == MERGE_DIRECTORY_RENAMES_NONE) { + renames->cached_pairs_valid_side = 0; /* neither side valid */ + return; + } + /* * Handle other cases; note that merge_trees[0..2] will only * be NULL if opti is, or if all three were manually set to @@ -5258,7 +5285,7 @@ void merge_incore_nonrecursive(struct merge_options *opt, trace2_region_enter("merge", "merge_start", opt->repo); assert(opt->ancestor != NULL); - merge_check_renames_reusable(result, merge_base, side1, side2); + merge_check_renames_reusable(opt, result, merge_base, side1, side2); merge_start(opt, result); /* * Record the trees used in this merge, so if there's a next merge in diff --git a/t/t3650-replay-basics.sh b/t/t3650-replay-basics.sh index cade7930765..58b37599357 100755 --- a/t/t3650-replay-basics.sh +++ b/t/t3650-replay-basics.sh @@ -195,7 +195,7 @@ test_expect_success 'using replay on bare repo to rebase multiple divergent bran done ' -test_expect_failure 'merge.directoryRenames=false' ' +test_expect_success 'merge.directoryRenames=false' ' # create a test case that stress-tests the rename caching git switch -c rename-onto && From patchwork Thu Mar 13 02:46:41 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elijah Newren X-Patchwork-Id: 14014233 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D34A13CF9C for ; Thu, 13 Mar 2025 02:46:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834012; cv=none; b=MMUWDqxW2+FKXsl9rn1srfzMcIP+9vmCT08eO/3R1XeNIR0vbpIUPWSFKc1AvozKGih4TQz/VWqIz6IWBE8zTXkqqpgD7iRQ8Qi9Vco7YD3YCJ4yGI8ESgfQDLVhG8wiUfcvgc5+tExvUnVhm/+YpVdwmDbH/RKtJy9DfdIINvI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741834012; c=relaxed/simple; bh=UUFw6+VUYHBmkpKv70O/p8+k2qGd1MG81EaFBOZNAvI=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=Y8gaGVpy5TRxH0ekoXoqGo9RANZ5IZkTg2pWnLLfGyBYdPnroljo9Q8kdKZL6ebyEowUt+9T1FjJy/uIqTODKrZWjrXxr+FipCJFhBEZYftAHsocq/ndi8hKGsjs5bQ2xUN5oD/I97ZenBHJH10ahRMFYsRtDmzxboRYK8yDguM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iyxmDTDe; arc=none smtp.client-ip=209.85.208.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iyxmDTDe" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5e5e22e6ed2so554490a12.3 for ; Wed, 12 Mar 2025 19:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741834008; x=1742438808; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=0L2g553xjOaDOe60VhZzNnI/qTrlgsQ+SYs2p0s4Dvk=; b=iyxmDTDeZlQr34FlcEkF9xcymJkp5aj7VePFYolpJ4ZJ3PvAOVt++Hg6UHOGaOlnJh K30qa0iqtNzxN9cIhZB124s+SWZATSwKBzmwopV7gnTrZQvO/lkgb7A7D6z7OKMJm4ui c8cZWl5fqVnWCdse4I5jBkN4MxhN2IcZCgtbUYOI6abnGKy1VbaSfSUpodXSjl3EZrmy P6zOL9UiXHXhx9dXbfnI08caBv9OakyZjPbImSs3T8KnfrwCVZxR7n+3XI43rMDe03Hu 1IV9ojw3ENF3KmbEWC89I8/JvPxBZVlYiuU74Lk0kGyaP6Ev94uWcEY4Ae8Lq4myoWiJ Ppfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741834008; x=1742438808; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0L2g553xjOaDOe60VhZzNnI/qTrlgsQ+SYs2p0s4Dvk=; b=BsIy6upPHzRreD9lS/XGzSBu4y039hLt+f/t3ziyhlKrEQV0nL1Ew6VRyoyPGN5djN Z4V0fOw0ZwVpQoBWqhlS8zy9ngaQZneUysitpuKQ2TUxFYGuHUQVc6UvIRvOlsPBR/Wf x507RuuCgwV1fHOdojuSpoRMiQjIYf7es6mdmr8Ss0wod3yK9VcKx8l/Wmk8cZBVPMOo eXa4rC0b+YtHlUpLonvCqPbuvbBTiCvVAXvpampaaSfSFsNlj/Co+Rsj+aTOghiAkxn6 BB6tdGPMmOX67ajp2lSv8XyoJ2Hk0tciEytGE9uxFUI0HaJ3Q7HLR9WUlIKgQ9QeMF2g 0eOg== X-Gm-Message-State: AOJu0YzmMlGWGA6uOeAXr7sKv9RvpxrfCeiiObDvebuLviezqU/VvFWt GbzFAPbP7wlR1X+3pVhm1rlTioW9CBG29T/xYlsEl5rWo5wIZpvmyNxrcg== X-Gm-Gg: ASbGnctf1yjj58uaGL47P+diUXzNxNTrs5SGyai5MKY3as6bEvMNgb4vbpFZ1MUpK6D /npzKmIXmRHqLO1KczMKMpxZYXxIsCk0BCUOlBJAa4mK3ewllcOJ0GAlbmmNTxPUwDbRQX5/xKy AGZsKvP2IZjspsysjUYmhRZA4f0EbsvSVjoGr6Av00cUJWtlLqn2dL3IWjM+5WF94Iz5BP/2TLJ J68ddl8JJiUh2gr5oW9LWy+KZ5MyJjb2cjJuOsB6lw/eJaYmnTERLCu+SxBw2TPzh04cNadReRa AfgcMetmTMHY+hzufQ65+eIlpFE1hXdlLSfmh3nyqRHLX2UHiwwUi170 X-Google-Smtp-Source: AGHT+IFeAZ7Dznnq5mJMD1elny6nSaoBSEqziKVW6WOjRPeLa+E7QODVmw8lwnDVXcGJByq7AVlvgQ== X-Received: by 2002:a05:6402:518a:b0:5e5:437b:74a7 with SMTP id 4fb4d7f45d1cf-5e5e22d915amr27911425a12.8.1741834007875; Wed, 12 Mar 2025 19:46:47 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e816ad38f3sm195482a12.63.2025.03.12.19.46.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Mar 2025 19:46:47 -0700 (PDT) Message-Id: <3f4b74eb3b934c62edb23b69db7460e3e0b44877.1741834001.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Thu, 13 Mar 2025 02:46:41 +0000 Subject: [PATCH v2 6/6] am: switch from merge_recursive_generic() to merge_ort_generic() Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: Patrick Steinhardt , Taylor Blau , Elijah Newren , Elijah Newren , Elijah Newren From: Elijah Newren From: Elijah Newren Switch from merge-recursive to merge-ort. Adjust the following testcases due to the switch: * t4151: This test left an untracked file in the way of the merge. merge-recursive could only sometimes tell when untracked files were in the way, and by the time it discovers others, it has already made too many changes to back out of the merge. So, instead of writing the results to e.g. 'file1' it would instead write them to 'file1~branch1'. This is confusing for users, because they might not notice 'file1~branch1' and accidentally add and commit 'file1'. In contrast, merge-ort correctly notices the file in the way before making any changes and aborts. Since this test didn't care about the file in the way, just remove it before calling git-am. * t4255: Usage of merge-ort allows us to change two known failures into successes. * t6427: As noted a few commits ago, the choice of conflict label for diff3 markers for the ancestor commit was previously handled by merge-recursive.c rather than by callers. Since that has now changed, `git am` needs to specify that label. Although the previous conflict label ("constructed merge base") was already fairly somewhat slanted towards `git am`, let's use wording more along the lines of the related command-line flag from `git apply` and function involved to tie it more closely to `git am`. Signed-off-by: Elijah Newren --- builtin/am.c | 5 +++-- t/t4151-am-abort.sh | 2 +- t/t4255-am-submodule.sh | 1 - t/t6427-diff3-conflict-markers.sh | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index 2921bb89ef1..3b61bd4c333 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -31,7 +31,7 @@ #include "preload-index.h" #include "sequencer.h" #include "revision.h" -#include "merge-recursive.h" +#include "merge-ort-wrappers.h" #include "log-tree.h" #include "notes-utils.h" #include "rerere.h" @@ -1638,12 +1638,13 @@ static int fall_back_threeway(const struct am_state *state, const char *index_pa o.branch1 = "HEAD"; their_tree_name = xstrfmt("%.*s", linelen(state->msg), state->msg); o.branch2 = their_tree_name; + o.ancestor = "constructed fake ancestor"; o.detect_directory_renames = MERGE_DIRECTORY_RENAMES_NONE; if (state->quiet) o.verbosity = 0; - if (merge_recursive_generic(&o, &our_tree, &their_tree, 1, bases, &result)) { + if (merge_ort_generic(&o, &our_tree, &their_tree, 1, bases, &result)) { repo_rerere(the_repository, state->allow_rerere_autoupdate); free(their_tree_name); return error(_("Failed to merge in the changes.")); diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh index edb38da7010..8e1ecf8a685 100755 --- a/t/t4151-am-abort.sh +++ b/t/t4151-am-abort.sh @@ -112,7 +112,7 @@ test_expect_success 'am --abort will keep dirty index intact' ' test_expect_success 'am -3 stops on conflict on unborn branch' ' git checkout -f --orphan orphan && git reset && - rm -f otherfile-4 && + rm -f file-1 otherfile-4 && test_must_fail git am -3 0003-*.patch && test 2 -eq $(git ls-files -u | wc -l) && test 4 = "$(cat otherfile-4)" diff --git a/t/t4255-am-submodule.sh b/t/t4255-am-submodule.sh index a7ba08f728c..e6679a01b44 100755 --- a/t/t4255-am-submodule.sh +++ b/t/t4255-am-submodule.sh @@ -19,7 +19,6 @@ am_3way () { $2 git am --3way patch } -KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES=1 test_submodule_switch_func "am_3way" test_expect_success 'setup diff.submodule' ' diff --git a/t/t6427-diff3-conflict-markers.sh b/t/t6427-diff3-conflict-markers.sh index dd5fe6a4021..57569c4f4bd 100755 --- a/t/t6427-diff3-conflict-markers.sh +++ b/t/t6427-diff3-conflict-markers.sh @@ -207,7 +207,7 @@ test_expect_success 'rebase --apply describes fake ancestor base' ' cd rebase && git rebase --abort && test_must_fail git -c merge.conflictstyle=diff3 rebase --apply main && - grep "||||||| constructed merge base" file + grep "||||||| constructed fake ancestor" file ) '