From: Junio C Hamano <gitster@pobox.com>
To: "sunlin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, sunlin <sunlin7@yahoo.com>,
"lin.sun" <lin.sun@zoom.us>
Subject: Re: [PATCH v3] Enable auto-merge for meld to follow the vim-diff beharior
Date: Mon, 29 Jun 2020 17:06:13 -0700 [thread overview]
Message-ID: <xmqqeepxfmdm.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <pull.781.v3.git.git.1593414441313.gitgitgadget@gmail.com> (sunlin via GitGitGadget's message of "Mon, 29 Jun 2020 07:07:21 +0000")
"sunlin via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: "lin.sun" <lin.sun@zoom.us>
The way this "name <addr>" is spelled must match the name used on
the Signed-off-by: line below.
> The mergetool "meld" does NOT merge the no-conflict changes, while the
> mergetool "vimdiff" will merge the no-conflict parts and highlight the
> conflict parts.
OK.
Have a blank line between paragraphs here.
> This patch will make the mergetool "meld" similar to "vimdiff",
> auto-merge the no-conflict parts, highlight conflict parts.
Give an order to the codebase to be like so, e.g.:
Make the mergetool used with "meld" backend behave similarly to
how "vimdiff" beheaves by telling it to auto-merge parts without
conflicts and highlight the parts with conflicts.
or somethin glike that.
> Signed-off-by: Lin Sun <lin.sun@zoom.us>
> ---
> Enable auto-merge for meld to follow the vimdiff beharior
>
> Hi, the mergetool "meld" does NOT merge the no-conflict changes, while
> the mergetool "vimdiff" will merge the no-conflict changes and highlight
> the conflict parts. This patch will make the mergetool "meld" similar to
> "vimdiff", auto-merge the no-conflict changes, highlight conflict parts.
That repeats the log message and does not add much useful info.
> mergetools/meld | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/mergetools/meld b/mergetools/meld
> index 7a08470f88..91b65ff22c 100644
> --- a/mergetools/meld
> +++ b/mergetools/meld
> @@ -7,13 +7,23 @@ merge_cmd () {
> then
> check_meld_for_output_version
> fi
> + if test -z "${meld_has_auto_merge_option:+set}"
> + then
> + check_meld_for_auto_merge_version
> + fi
The detection part looks clumsy and inefficient. More about it later.
> + option_auto_merge=
> + if test "$meld_has_auto_merge_option" = true
> + then
> + option_auto_merge="--auto-merge"
> + fi
>
> if test "$meld_has_output_option" = true
> then
> - "$merge_tool_path" --output="$MERGED" \
> + "$merge_tool_path" $option_auto_merge --output="$MERGED" \
> "$LOCAL" "$BASE" "$REMOTE"
> else
> - "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
> + "$merge_tool_path" $option_auto_merge "$LOCAL" "$MERGED" "$REMOTE"
> fi
> }
The part that chooses whether to pass --auto-merge or not and
adjusts the command line options does look sensible.
I wonder if the same "hasAutoMerge" option can be used by those who
do *not* want the new --auto-merge behaviour to opt out of this
change. Is there a reason why "meld" offers the --auto-merge as an
optional behaviour (which tells, at least to me, that the default
behaviour is not to auto-merge and makes me assume that the default
must be chosen by some sound reasoning, hence some users would prefer
not to use this new behaviour with good reasons)?
I guess what I am trying to get at is, if --auto-merge is an optional
and non-default behaviour for "meld" users, perhaps it is not a good
idea to change the behaviour on them only because the version of meld
they run happens to support the --auto-merge as an optional behaviour.
IOW, wouldn't it make more sense, and certainly make it safer
without surprises to existing users, if we made the logic to
* If mergetool.meld.useAutoMerge is not set, do not pass
--auto-merge whether "meld" supports the option or not.
* If mergetool.meld.useAutoMerge is 'true', always pass it
without checking.
* If mergetool.meld.useAutoMerge is 'when-able' (or come up with
a better name if you want, perhaps 'auto'), check if "meld"
accepts "--auto-merge" and decide whether to pass it or not.
perhaps?
> +# Check whether we should use 'meld --auto-merge ...'
> +check_meld_for_auto_merge_version () {
> + meld_path="$(git config mergetool.meld.path)"
> + meld_path="${meld_path:-meld}"
> +
> + if meld_has_auto_merge_option=$(git config --bool mergetool.meld.hasAutoMerge)
> + then
> + : use configured value
> + elif "$meld_path" --help 2>&1 |
> + grep -e '--auto-merge' -e '\[OPTION\.\.\.\]' >/dev/null
> + then
> + : old ones mention --auto-merge and new ones just say OPTION...
> + meld_has_auto_merge_option=true
> + else
> + meld_has_auto_merge_option=false
> + fi
> +}
When not configured, we end up running "meld --help" twice for two
options, which is not great, don't you think? I actually think the
part that runs "meld --help" and parses its output should be split
out of the helper function "check_meld_for_output_version" and
called "check_meld_supported_options" or something, so that the
logic to see if the --output and --auto-merge options should be
passed can be made with at most one invocation of "meld --help".
Which may involve *NOT* having two separate helper functions
check_meld_for_*_version for the tested features.
Oh, also, check_meld_for_*_version is nonsensical as a name for
these helper functions (it is not the fault of this patch---it is
mimicking the existing practice, but that does not make the function
name not nonsensical). The helpers do not actually want to check a
"version", they only want to see if a feature is supported. So
having "feature" in the name would be good, but "version" is not.
next prev parent reply other threads:[~2020-06-30 0:07 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 1:25 [PATCH] Enable auto-merge for meld to follow the vim-diff beharior sunlin via GitGitGadget
2020-06-08 9:49 ` Pratyush Yadav
2020-06-09 3:19 ` [PATCH v2] " sunlin via GitGitGadget
2020-06-29 7:07 ` [PATCH v3] " sunlin via GitGitGadget
2020-06-29 12:32 ` Fwd: " Git Gadget
2020-06-30 0:06 ` Junio C Hamano [this message]
2020-06-30 7:42 ` David Aguilar
2020-06-30 11:25 ` lin.sun
2020-06-30 11:37 ` lin.sun
2020-06-30 15:51 ` Junio C Hamano
2020-06-30 11:26 ` [PATCH v4] " sunlin via GitGitGadget
2020-06-30 16:23 ` Đoàn Trần Công Danh
2020-06-30 23:01 ` Đoàn Trần Công Danh
2020-07-01 7:06 ` [PATCH v5] " sunlin via GitGitGadget
2020-07-01 7:23 ` lin.sun
2020-07-01 18:19 ` David Aguilar
2020-07-01 14:17 ` Đoàn Trần Công Danh
2020-07-01 15:32 ` lin.sun
2020-07-01 22:02 ` lin.sun
2020-07-01 23:06 ` Đoàn Trần Công Danh
2020-07-01 19:51 ` Junio C Hamano
2020-07-02 0:20 ` lin.sun
2020-07-02 0:44 ` [PATCH v6] Support auto-merge for meld to follow the vim-diff behavior sunlin via GitGitGadget
2020-07-02 2:35 ` lin.sun
2020-07-03 1:50 ` Junio C Hamano
2020-07-03 3:53 ` lin.sun
2020-07-03 15:58 ` Đoàn Trần Công Danh
2020-07-06 6:23 ` Junio C Hamano
2020-07-03 3:26 ` [PATCH v7] " sunlin via GitGitGadget
2020-07-03 4:50 ` Junio C Hamano
2020-07-04 1:18 ` lin.sun
2020-07-06 2:36 ` lin.sun
2020-07-04 1:16 ` [PATCH v8] " sunlin via GitGitGadget
2020-07-06 2:27 ` [PATCH v9] " sunlin via GitGitGadget
2020-07-06 22:31 ` Junio C Hamano
2020-07-07 6:34 ` lin.sun
2020-07-07 16:43 ` Junio C Hamano
2020-07-08 1:20 ` lin.sun
2020-07-08 1:51 ` Junio C Hamano
2020-07-07 6:17 ` [PATCH v10] " sunlin via GitGitGadget
2020-07-07 6:25 ` Junio C Hamano
2020-07-07 6:38 ` lin.sun
2020-07-07 6:44 ` lin.sun
2020-07-07 7:13 ` [PATCH v11] " sunlin via GitGitGadget
2020-07-07 15:31 ` Đoàn Trần Công Danh
2020-07-08 0:57 ` lin.sun
2020-07-08 3:25 ` [PATCH v12] " sunlin via GitGitGadget
2020-07-08 3:31 ` lin.sun
2020-07-08 15:42 ` Đoàn Trần Công Danh
2020-07-08 15:47 ` lin.sun
2020-07-09 0:35 ` [PATCH v13] " sunlin via GitGitGadget
2020-07-09 0:39 ` lin.sun
2020-07-09 2:42 ` Junio C Hamano
2020-07-09 2:56 ` Junio C Hamano
2020-07-09 3:24 ` lin.sun
2020-07-09 4:49 ` Junio C Hamano
2020-07-09 5:31 ` Junio C Hamano
2020-07-12 14:07 ` lin.sun
2020-07-12 23:38 ` lin.sun
2020-07-09 4:28 ` [PATCH v14] " sunlin via GitGitGadget
2020-07-12 8:39 ` [PATCH v15] " sunlin via GitGitGadget
2020-07-12 9:08 ` [PATCH v16] " sunlin via GitGitGadget
2020-07-12 18:04 ` Junio C Hamano
2020-07-12 23:26 ` lin.sun
2020-07-13 5:14 ` Junio C Hamano
2020-07-13 6:58 ` lin.sun
2020-07-12 23:32 ` [PATCH v17] " sunlin via GitGitGadget
2020-07-24 0:58 ` Junio C Hamano
2020-09-03 21:48 ` Junio C Hamano
[not found] ` <C35AC799-B4F6-4A5E-92FA-21065310B379@hxcore.ol>
2020-09-09 1:31 ` Lin Sun
2020-09-09 20:43 ` Junio C Hamano
2020-09-12 7:21 ` [PATCH v18] " sunlin via GitGitGadget
2020-09-14 20:07 ` Junio C Hamano
2020-09-15 0:55 ` Lin Sun
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeepxfmdm.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=lin.sun@zoom.us \
--cc=sunlin7@yahoo.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).