Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: David Aguilar <davvid@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: sunlin via GitGitGadget <gitgitgadget@gmail.com>,
	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: Tue, 30 Jun 2020 00:42:04 -0700
Message-ID: <20200630074204.GA2144485@gmail.com> (raw)
In-Reply-To: <xmqqeepxfmdm.fsf@gitster.c.googlers.com>

On Mon, Jun 29, 2020 at 05:06:13PM -0700, Junio C Hamano wrote:
> "sunlin via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >  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.


Sorry for not noticing your reply here earlier.  I agree with everything
you wrote here, and rescind my earlier sign-off.  Combining as you
suggested below is best IMO as well.

> 
> > +	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?


I like the idea of having it be auto/true/false, and perhaps "auto"
would be a sensible default if more users benefit from it than not.

Sunlin, do you have an opinion on what the default should be?



> > +# Check whether we should use 'meld --auto-merge ...'
> > +check_meld_for_auto_merge_version () {
> > +	meld_path="$(git config mergetool.meld.path)"

Small sug -- this command substitution doesn't need the enclosing
quotes.

	meld_path=$(git config mergetool.meld.path || echo meld)

should be sufficient.  Are we okay with `|| echo meld`?
If so, it would let us drop this line below.

> > +	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.


I'm 100% on board with this suggestion.

> 
> 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.


Ditto.
-- 
David

  reply index

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  1:25 [PATCH] " 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 [this message]
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

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=20200630074204.GA2144485@gmail.com \
    --to=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git