From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: phillip.wood@dunelm.org.uk,
Izzy via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
Izzy <winglovet@gmail.com>
Subject: Re: [PATCH v6] merge-tree: add -X strategy option
Date: Mon, 09 Oct 2023 10:10:28 -0700 [thread overview]
Message-ID: <xmqq4jiz3env.fsf@gitster.g> (raw)
In-Reply-To: <20231009155315.GA3252778@coredump.intra.peff.net> (Jeff King's message of "Mon, 9 Oct 2023 11:53:15 -0400")
Jeff King <peff@peff.net> writes:
> I agree that struct-copying is an unusual pattern, and we'd potentially
> run into problems with duplication. But I think it is even trickier than
> that here. We also go on to actually _modify_ opt in this function,
> assigning to various members (both directly, and I think the merge code
> itself will write to opt->priv).
>
> So if we use a pointer (rather than struct assignment), those changes
> will persist in the merge_options struct that was passed in. Which is
> also weird.
>
> Between the two, I think using a pointer is probably the least-weird.
> This real_merge() function is only called once, and is a static-local
> helper for cmd_merge_tree(). So the two functions work as a single unit,
> and munging "opt" is not a big deal.
It is called once per --stdin input to perform many merges in a row.
The most obvious "structure to pointer to structure" conversion
below seems to break an assertion (which is not very surprising, as
it happens inside that --stdin loop), so I am tempted to revert the
whole thing for now.
Thanks.
git: merge-ort.c:5110: merge_incore_recursive: Assertion `opt->ancestor == NULL' failed.
./test-lib.sh: line 1067: 738791 Done printf "c1 c3\nc2 -- c1 c3\nc2 c3"
738792 Aborted | git -C repo merge-tree --stdin > actual
builtin/merge-tree.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git c/builtin/merge-tree.c w/builtin/merge-tree.c
index 7024b5ce2e..1cb1fba2de 100644
--- c/builtin/merge-tree.c
+++ w/builtin/merge-tree.c
@@ -425,7 +425,7 @@ static int real_merge(struct merge_tree_options *o,
{
struct commit *parent1, *parent2;
struct commit_list *merge_bases = NULL;
- struct merge_options opt = o->merge_options;
+ struct merge_options *opt = &o->merge_options;
struct merge_result result = { 0 };
int show_messages = o->show_messages;
@@ -439,10 +439,10 @@ static int real_merge(struct merge_tree_options *o,
help_unknown_ref(branch2, "merge-tree",
_("not something we can merge"));
- opt.show_rename_progress = 0;
+ opt->show_rename_progress = 0;
- opt.branch1 = branch1;
- opt.branch2 = branch2;
+ opt->branch1 = branch1;
+ opt->branch2 = branch2;
if (merge_base) {
struct commit *base_commit;
@@ -452,11 +452,11 @@ static int real_merge(struct merge_tree_options *o,
if (!base_commit)
die(_("could not lookup commit '%s'"), merge_base);
- opt.ancestor = merge_base;
+ opt->ancestor = merge_base;
base_tree = repo_get_commit_tree(the_repository, base_commit);
parent1_tree = repo_get_commit_tree(the_repository, parent1);
parent2_tree = repo_get_commit_tree(the_repository, parent2);
- merge_incore_nonrecursive(&opt, base_tree, parent1_tree, parent2_tree, &result);
+ merge_incore_nonrecursive(opt, base_tree, parent1_tree, parent2_tree, &result);
} else {
/*
* Get the merge bases, in reverse order; see comment above
@@ -467,7 +467,7 @@ static int real_merge(struct merge_tree_options *o,
if (!merge_bases && !o->allow_unrelated_histories)
die(_("refusing to merge unrelated histories"));
merge_bases = reverse_commit_list(merge_bases);
- merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result);
+ merge_incore_recursive(opt, merge_bases, parent1, parent2, &result);
}
if (result.clean < 0)
@@ -501,12 +501,12 @@ static int real_merge(struct merge_tree_options *o,
}
if (show_messages) {
putchar(line_termination);
- merge_display_update_messages(&opt, line_termination == '\0',
+ merge_display_update_messages(opt, line_termination == '\0',
&result);
}
if (o->use_stdin)
putchar(line_termination);
- merge_finalize(&opt, &result);
+ merge_finalize(opt, &result);
return !result.clean; /* result.clean < 0 handled above */
}
next prev parent reply other threads:[~2023-10-09 17:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-05 14:24 [PATCH] merge-tree: add -X strategy option Izzy via GitGitGadget
2023-08-07 2:10 ` Junio C Hamano
2023-08-12 5:33 ` [PATCH v2] " Izzy via GitGitGadget
2023-08-12 5:41 ` 唐宇奕
2023-09-03 1:31 ` 唐宇奕
2023-09-12 15:03 ` Elijah Newren
2023-09-16 2:14 ` [PATCH v3] " Izzy via GitGitGadget
2023-09-16 2:26 ` 唐宇奕
2023-09-16 3:21 ` Elijah Newren
2023-09-16 3:16 ` Elijah Newren
2023-09-16 3:47 ` [PATCH v4] " Izzy via GitGitGadget
2023-09-16 3:55 ` Elijah Newren
2023-09-16 4:04 ` 唐宇奕
2023-09-16 6:11 ` Jeff King
2023-09-16 8:37 ` [PATCH v5] " Izzy via GitGitGadget
2023-09-16 8:38 ` 唐宇奕
2023-09-18 9:53 ` Phillip Wood
2023-09-18 16:08 ` Junio C Hamano
2023-09-24 2:23 ` [PATCH v6] " Izzy via GitGitGadget
2023-09-24 2:26 ` 唐宇奕
2023-10-09 9:58 ` Phillip Wood
2023-10-09 15:53 ` Jeff King
2023-10-09 17:10 ` Junio C Hamano [this message]
2023-10-09 18:52 ` Jeff King
2023-10-11 19:38 ` Junio C Hamano
2023-10-11 21:43 ` Jeff King
2023-10-11 22:19 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4jiz3env.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=winglovet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.