Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Aguilar <davvid@gmail.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 08:51:25 -0700
Message-ID: <xmqq1rlwft6q.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200630074204.GA2144485@gmail.com> (David Aguilar's message of "Tue, 30 Jun 2020 00:42:04 -0700")

David Aguilar <davvid@gmail.com> writes:

> On Mon, Jun 29, 2020 at 05:06:13PM -0700, Junio C Hamano wrote:
> ...
>> 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.

The principle I've stuck to running this project for the past years
is to avoid hurting 1 user more than trying to please 10 others.  As
I do not use meld regularly myself, I do not know if there are use
cases that are helped by the fact that "--auto-merge" is not the
default behaviour among "meld" users (not limited to "users of
mergetool with meld backend").  And if there are, suddenly changing
the behaviour to those who have happily been using mergetool with
meld backend that does not "--auto-merge" can be disservice to our
users.  Until I hear something along the lines of "Even though meld
requires --auto-merge from users merely due to historical reasons,
these days everybody hates the fact that it is not the default", I'd
recommend against making 'auto' the default on our side, just to be
safe, even if our intuition is that majority of users may want the
"--auto-merge" behaviour.

But I am not a user of mergetool with meld backend, so...

Thanks.

  parent 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
2020-06-30 11:25         ` lin.sun
2020-06-30 11:37         ` lin.sun
2020-06-30 15:51         ` Junio C Hamano [this message]
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=xmqq1rlwft6q.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=davvid@gmail.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

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