All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: David Aguilar <davvid@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 7/7] mergetool--lib: Improve show_tool_help() output
Date: Fri, 25 Jan 2013 21:16:01 +0000	[thread overview]
Message-ID: <20130125211601.GD7498@serenity.lan> (raw)
In-Reply-To: <7vlibh2d8a.fsf@alter.siamese.dyndns.org>

On Fri, Jan 25, 2013 at 12:56:37PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> 
> > On Fri, Jan 25, 2013 at 12:16:42PM -0800, Junio C Hamano wrote:
> >> John Keeping <john@keeping.me.uk> writes:
> >> 
> >> > Actually, can we just change all of the above part of the loop to:
> >> >
> >> > 	test "$tool" = defaults && continue
> >> >
> >> > 	merge_tool_path=$(
> >> > 		setup_tool "$tool" >/dev/null 2>&1 &&
> >> > 		translate_merge_tool_path "$tool"
> >> > 	) || continue
> >> 
> >> Meaning "setup_tool ought to know which mode we are in and should
> >> fail if we are in merge mode and it does not support merging"?  That
> >> line of reasoning makes tons of sense to me, compared to this script
> >> implementing that logic for these scriptlets.
> >
> > Yes, that's part of what setup_tool does.  It actually calls "exit" if
> > the "mode? && can_mode" test fails, which is why we need to call it in
> > the subshell.
> >
> > I think this would get even better if we add a preparatory patch like
> > this, so we can just call setup_tool and then set merge_tool_path:
> >
> > -- >8 --
> >
> > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> > index 888ae3e..4644cbf 100644
> > --- a/git-mergetool--lib.sh
> > +++ b/git-mergetool--lib.sh
> > @@ -67,11 +67,11 @@ setup_tool () {
> >  	if merge_mode && ! can_merge
> >  	then
> >  		echo "error: '$tool' can not be used to resolve merges" >&2
> > -		exit 1
> > +		return 1
> >  	elif diff_mode && ! can_diff
> >  	then
> >  		echo "error: '$tool' can only be used to resolve merges" >&2
> > -		exit 1
> > +		return 1
> >  	fi
> >  	return 0
> >  }
> > @@ -100,7 +100,7 @@ run_merge_tool () {
> >  	status=0
> >  
> >  	# Bring tool-specific functions into scope
> > -	setup_tool "$1"
> > +	setup_tool "$1" || return
> >  
> >  	if merge_mode
> >  	then
> >
> > -- 8< --
> >  
> >> How/when does translate_merge_tool_path fail?
> >
> > It doesn't - the "|| continue" is to catch errors from setup_tool.
> 
> Ugh.

Is that targeted at my suggestion at the top of this email or calling
exit in setup_tool?

With the patch above, the block of code at the top becomes:

 	test "$tool" = defaults && continue

 	setup_tool "$tool" 2>/dev/null || continue
 	merge_tool_path=$(translate_merge_tool_path "$tool")

which IMHO is pretty readable.


John

  reply	other threads:[~2013-01-25 21:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25  9:43 [PATCH 0/7] mergetool-lib improvements for --tool-help David Aguilar
2013-01-25  9:43 ` [PATCH 1/7] git-mergetool: move show_tool_help to mergetool--lib David Aguilar
2013-01-25  9:43 ` [PATCH 2/7] git-mergetool: remove redundant assignment David Aguilar
2013-01-25  9:43 ` [PATCH 3/7] git-mergetool: don't hardcode 'mergetool' in show_tool_help David Aguilar
2013-01-25  9:43 ` [PATCH 4/7] git-difftool: use git-mergetool--lib for "--tool-help" David Aguilar
2013-01-25  9:43 ` [PATCH 5/7] mergetools/vim: Remove redundant diff command David Aguilar
2013-01-25  9:43 ` [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim David Aguilar
2013-01-25 10:23   ` Sebastian Schuberth
2013-01-25 10:28     ` David Aguilar
2013-01-25 10:34       ` Sebastian Schuberth
2013-01-25 11:39         ` Sebastian Schuberth
2013-01-25 10:38   ` John Keeping
2013-01-25 10:40     ` David Aguilar
2013-01-25 19:11       ` Junio C Hamano
2013-01-25  9:43 ` [PATCH 7/7] mergetool--lib: Improve show_tool_help() output David Aguilar
2013-01-25 19:54   ` John Keeping
2013-01-25 20:06     ` Junio C Hamano
2013-01-25 20:08     ` John Keeping
2013-01-25 20:16       ` Junio C Hamano
2013-01-25 20:46         ` John Keeping
2013-01-25 20:56           ` Junio C Hamano
2013-01-25 21:16             ` John Keeping [this message]
2013-01-25 21:47               ` Junio C Hamano
2013-01-25 22:02                 ` John Keeping
2013-01-25 22:03                   ` [PATCH 8/7] mergetool--lib: don't call "exit" in setup_tool John Keeping
2013-01-26  0:24                     ` Junio C Hamano
2013-01-26  7:01                       ` David Aguilar
2013-01-26 12:17                       ` [PATCH 1/2 v2] " John Keeping
2013-01-26 13:50                         ` [PATCH 1/2 v3] " John Keeping
2013-01-25 22:04                   ` [PATCH 9/7] mergetool--lib: fix path lookup in guess_merge_tool John Keeping

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=20130125211601.GD7498@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.