From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Izzy via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
Jeff King <peff@peff.net>, Izzy <winglovet@gmail.com>
Subject: Re: [PATCH v5] merge-tree: add -X strategy option
Date: Mon, 18 Sep 2023 09:08:25 -0700 [thread overview]
Message-ID: <xmqqcyyfmpl2.fsf@gitster.g> (raw)
In-Reply-To: <67638fd7-ad63-4e20-87e1-bef121fef197@gmail.com> (Phillip Wood's message of "Mon, 18 Sep 2023 10:53:48 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> ...
> This is the right place to call parse_merge_opt() but I think we
> should first check that the user has requested a real merge rather
> than a trivial merge.
>
> if (xopts.nr && o.mode == MODE_TRIVIAL)
> die(_("--trivial-merge is incompatible with all other options"));
>
> Otherwise if the user passes in invalid strategy option to a trivial
> merge they'll get an error about an invalid strategy option rather
> than being told --strategy-option is not supported with
> --trivial-merge.
I presume that another issue with not having that compatibility
checking with "--trivial" would be when the user passes a valid
strategy option and it would be silently ignored.
> Ideally there would be a preparatory patch that moves the switch
> statement that is below the "if(o.use_stdin)" block up to this point
> so we'd always have set o.mode before checking if it is a trivial
> merge. (I think you'd to change the code slightly when it is moved to
> add a check for o.use_stdin)
That sounds very good.
Thanks for a good "stepping back a bit" review. Highly appreciated.
next prev parent reply other threads:[~2023-09-18 16: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 [this message]
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
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=xmqqcyyfmpl2.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.wood123@gmail.com \
--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.