From: David Aguilar <davvid@gmail.com>
To: lin.sun@zoom.us
Cc: "'sunlin via GitGitGadget'" <gitgitgadget@gmail.com>,
git@vger.kernel.org,
"'Đoàn Trần Công Danh'" <congdanhqx@gmail.com>,
"'Junio C Hamano'" <gitster@pobox.com>
Subject: Re: [PATCH v5] Enable auto-merge for meld to follow the vim-diff beharior
Date: Wed, 1 Jul 2020 11:19:47 -0700 [thread overview]
Message-ID: <20200701181947.GA16794@gmail.com> (raw)
In-Reply-To: <1514701d64f78$970ba180$c522e480$@zoom.us>
On Wed, Jul 01, 2020 at 03:23:56PM +0800, lin.sun@zoom.us wrote:
> Hi Danh,
>
> The [PATH v5] is changed to following the comments from you, Junio, David.
> Please review this newer version. Thank you.
> The raw files is https://github.com/git/git/blob/344817d57970e3ac0910cdd8ad47bf97334ab2a6/mergetools/meld
>
> Regards
> Lin
> -----Original Message-----
> From: sunlin via GitGitGadget <gitgitgadget@gmail.com>
> Sent: Wednesday, July 1, 2020 15:07
> To: git@vger.kernel.org
> Cc: sunlin <sunlin7@yahoo.com>; Lin Sun <lin.sun@zoom.us>
> Subject: [PATCH v5] Enable auto-merge for meld to follow the vim-diff beharior
>
> From: Lin Sun <lin.sun@zoom.us>
>
> Make the mergetool used with "meld" backend behave similarly to how "vimdiff" behavior by telling it to auto-merge parts without conflicts and highlight the parts with conflicts when configuring `mergetool.meld.hasAutoMerge` with `true`, or `auto` for automatically detecting the option.
Please word-wrap commit messages to 72 chars or less.
>
> Signed-off-by: Lin Sun <lin.sun@zoom.us>
> ---
> Documentation/config/mergetool.txt | 8 ++++
> mergetools/meld | 72 +++++++++++++++++++++++-------
> 2 files changed, 64 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/config/mergetool.txt b/Documentation/config/mergetool.txt
> index 09ed31dbfa..9a74bd98dc 100644
> --- a/Documentation/config/mergetool.txt
> +++ b/Documentation/config/mergetool.txt
> @@ -30,6 +30,14 @@ mergetool.meld.hasOutput::
> to `true` tells Git to unconditionally use the `--output` option,
> and `false` avoids using `--output`.
>
> +mergetool.meld.hasAutoMerge::
> + Older versions of `meld` do not support the `--auto-merge` option.
> + Setting `mergetool.meld.hasOutput` to `true` tells Git to
> + unconditionally use the `--auto-merge` option, and `false` avoids using
> + `--auto-merge`, and `auto` detect whether `meld` supports `--auto-merge`
> + by inspecting the output of `meld --help`, otherwise, follow meld's
> + default behavior.
> +
Now that we've decided that "false" should be the default behavior, the
naming of this option don't make sense. "hasAutoMerge" doesn't
really convey what this option does anymore. I would suggest calling it
"mergetool.meld.automerge".
Perhaps something like this?
mergetool.meld.automerge::
Older versions of `meld` do not support the `--auto-merge`
option. Setting `mergetool.meld.automerge` to `true` tells Git
to unconditionally use the `--auto-merge` option with `meld`.
Setting this value to `auto` makes git detect whether
`--auto-merge` is supported and will only use `--auto-merge`
when available. A value of `false` avoids using `--auto-merge`
altogether, and is the default value.
> @@ -3,34 +3,74 @@ diff_cmd () {
> }
>
> merge_cmd () {
> - if test -z "${meld_has_output_option:+set}"
> + check_meld_for_features
> +
> + option_auto_merge=
> + if test "$meld_has_auto_merge_option" = true
> then
> - check_meld_for_output_version
> + 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
> }
>
> -# Check whether we should use 'meld --output <file>'
> -check_meld_for_output_version () {
> - meld_path="$(git config mergetool.meld.path)"
> - meld_path="${meld_path:-meld}"
> +# Get meld help message
> +get_meld_help_msg () {
This comment seems redundant when the function is called
get_meld_help_msg().
> + meld_path="$(git config mergetool.meld.path || echo meld)"
> + $meld_path --help 2>&1
> +}
>
> - if meld_has_output_option=$(git config --bool mergetool.meld.hasOutput)
> +# Check the features and set flags
> +check_meld_for_features () {
Ditto for this comment.
> + # Check whether we should use 'meld --output <file>'
> + if test -z "${meld_has_output_option:+set}"
> then
> - : use configured value
> - elif "$meld_path" --help 2>&1 |
> - grep -e '--output=' -e '\[OPTION\.\.\.\]' >/dev/null
> + meld_has_output_option=$(git config --bool mergetool.meld.hasOutput)
> + if test "$meld_has_output_option" = true -o \
> + "$meld_has_output_option" = false
Documentation/CodingGuidelines mentions:
- We do not write our "test" command with "-a" and "-o" and use "&&"
or "||" to concatenate multiple "test" commands instead, because
the use of "-a/-o" is often error-prone. E.g.
This would be written as:
if test "$meld_has_output_option" = true ||
test "$meld_has_output_option" = false
then
...
fi
Instead of two checks, would it be better to instead just check:
if test -n "$meld_has_output_option"
?
git config --bool will only ever produce true/false, so we really only
need to check that it's a non-empty value, perhaps?
> + case "$meld_help_msg" in
> + *"--output="* | *"[OPTION"???"]"*)
> + # old ones mention --output and new ones just say OPTION...
> + meld_has_output_option=true ;;
> + *)
> + meld_has_output_option=false ;;
> + esac
We typically avoid the extra indentation level for the case labels.
eg. this would be written like this (with ";;" on its own line):
case "$meld_help_msg" in
*--output=*|*"[OPTION"???"]"*)
# old ones mention --output and new ones just say OPTION...
meld_has_output_option=true
;;
*)
meld_has_output_option=false
;;
esac
Also, if you're matching [OPTION ...] would it work to just use
a single-quoted value in the case label? eg: *'[OPTION...]'* ?
> + if test -z "${meld_has_auto_merge_option:+set}"
> then
> - : old ones mention --output and new ones just say OPTION...
> - meld_has_output_option=true
> - else
> - meld_has_output_option=false
> + meld_has_auto_merge_option=$(git config mergetool.meld.hasAutoMerge)
> + if test "$meld_has_auto_merge_option" = auto
> + then
> + # testing the "--auto-merge" option only if config is "auto"
> + if test -z "$meld_help_msg"
> + then
> + meld_help_msg="$(get_meld_help_msg)"
This can just be:
meld_help_msg=$(get_meld_help_msg)
and can do without the surrounding " " double quotes.
> + case "$meld_help_msg" in
> + *"--auto-merge"*)
> + : old ones mention --output and new ones just say OPTION...
> + meld_has_auto_merge_option=true ;;
> + *)
> + meld_has_auto_merge_option=false ;;
> + esac
As above -- unindent the case statements, and put the ";;" case
statement terminators on their own line.
cheers,
--
David
next prev parent reply other threads:[~2020-07-01 18:19 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
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 [this message]
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=20200701181947.GA16794@gmail.com \
--to=davvid@gmail.com \
--cc=congdanhqx@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=lin.sun@zoom.us \
/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).