All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Seth House <seth@eseth.com>
Cc: David Aguilar <davvid@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org
Subject: Re: Re* [PATCH v2] fixup! mergetool: add automerge configuration
Date: Sun, 10 Jan 2021 03:24:48 -0800	[thread overview]
Message-ID: <xmqqh7np9gqn.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: 20210110072902.GA247325@ellen

Seth House <seth@eseth.com> writes:

> On Sat, Jan 09, 2021 at 10:40:20PM -0800, Junio C Hamano wrote:
>> An ugly workaround patch that caters only to difftool breakage is
>> attached at the end; I did not look if a similar treatment is
>> necessary for the mergetool side.
>
> That fixup does the trick on my machine too. Thank you.

Note that with t7800 fixed with the patch, non Windows jobs all seem
to pass, but t7610 seems to have problem(s) on Windows.

https://github.com/git/git/runs/1675932107?check_suite_focus=true#step:7:10373

> How wary are you of continuing with `initialize_merge_tool`? Do you see
> a better approach to get `automerge_enabled `into scope? While it is
> a nice feature to have, is it worth the risk vs. reward?

Hmph.  We need to have a way to define helper routines customized
for the tool, and in the codebase without this series, it is the job
for setup_tool.  It defines fallback implementations, allows tool
specific customizations.  

Your initialize_merge_tool is just a thin wrapper around setup_tool.
It calls setup_tool, and if the function exits with non-zero status,
returns with status==1 (and otherwise returns with status==0).  As I
expect all the callers of setup_tool or initialize_merge_tool would
either ignore the status or check if it succeeded (i.e. compare $?
against 0 and any non-zero values are treated equally), it does not
seem to do anything useful.

I think we may be able to get rid of initialize_merge_tool, but you
would need to call setup_tool in places initialize_merge_tool was
called in your patch, as you must have needed to make sure that the
tool specific customizations have been carried out before going
forward in these places.

So, no, I do not see a reason to be wary of initialize/setup.  

With or without the seemingly needless initialize wrapper, I think
calling setup before starting to do certain operations that need
tool specific customization is just necessary.  The same machanism
has been in use to give can_merge/can_diff to each tool and the way
it works ought to be fairly well understood.

It is a different story if it makes sense not to exit when you see
failure from initialize/setup, and instead _skip_ running helpers
like run_merge_tool.  It was just a mistake we all make every once
in a while (i.e. a bug), and I am reasonably sure that we will
introduce more of them but we will be capable of fixing all.

Thanks.

  reply	other threads:[~2021-01-10 11:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-09 21:49 [PATCH] fixup! mergetool: add automerge configuration David Aguilar
2021-01-09 21:59 ` brian m. carlson
2021-01-09 22:42   ` [PATCH v2] " David Aguilar
2021-01-09 22:54     ` Seth House
2021-01-10  1:17       ` Junio C Hamano
2021-01-10  6:40         ` Re* " Junio C Hamano
2021-01-10  7:29           ` Seth House
2021-01-10 11:24             ` Junio C Hamano [this message]
2021-01-16  4:24               ` Seth House
2021-01-20 23:24                 ` automerge implementation ideas for Windows Seth House
2021-01-21 22:50                   ` Junio C Hamano
2021-01-22  1:09                     ` Seth House
2021-01-22  2:26                       ` Junio C Hamano
2021-01-22  2:50                 ` Re* [PATCH v2] fixup! mergetool: add automerge configuration brian m. carlson
2021-01-22 16:29                   ` Johannes Schindelin
2021-01-22 23:25                     ` brian m. carlson
2021-01-26 14:32                       ` Johannes Schindelin
2021-01-26 18:06                         ` Seth House
2021-01-26 20:10                           ` Junio C Hamano
2021-01-27  3:37                             ` Seth House
2021-01-29  0:41                               ` Junio C Hamano
2021-01-09 23:18     ` Junio C Hamano
2021-01-10  1:52       ` Junio C Hamano
2021-01-09 23:21   ` [PATCH] " Junio C Hamano
2021-01-22  9:08 Re* [PATCH v2] " Seth House

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=xmqqh7np9gqn.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=davvid@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=seth@eseth.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.