git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Aguilar <davvid@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Tanguy Ortolo <tanguy+debian@ortolo.eu>,
	Charles Bailey <charles@hashpling.org>,
	Sebastian Schuberth <sschuberth@gmail.com>
Subject: Re: [PATCH 4/4] mergetools/meld: Use '--output' when available
Date: Thu, 18 Aug 2011 02:24:06 -0700	[thread overview]
Message-ID: <20110818092403.GB15416@gmail.com> (raw)
In-Reply-To: <20110818081309.GP31888@elie.gateway.2wire.net>

On Thu, Aug 18, 2011 at 03:13:10AM -0500, Jonathan Nieder wrote:
> David Aguilar wrote:
> 
> > use the '--output' option when available.
> 
> Yay. :)
> 
> > --- a/mergetools/meld
> > +++ b/mergetools/meld
> > @@ -4,6 +4,37 @@ diff_cmd () {
> >  
> >  merge_cmd () {
> >  	touch "$BACKUP"
> > -	"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
> > +	if test "$meld_has_output_option" = true
> > +	then
> > +		"$merge_tool_path" --output "$MERGED" \
> > +			"$BASE" "$LOCAL" "$REMOTE"
> 
> Shouldn't this be "$LOCAL" "$BASE" "$REMOTE"?

Yup, thanks.

> 
> > +	else
> > +		"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
> > +	fi
> >  	check_unchanged
> 
> I wonder if the version test could be made a little simpler (perhaps
> to cope better if future versions use a different numbering system):
> 
> 	if "$merge_tool_path" --output /dev/null --help >/dev/null 2>&1
> 	then
> 		"$merge_tool_path" --output ...
> 	else
> 		"$merge_tool_path" "$LOCAL" ...
> 	fi
> 
> Forgive my ignorance: is this function likely to be called in a loop?
> If so, it makes sense to precompute or cache the result of detection,
> like you already do.

Yes, it is called in a loop...


> 	check_meld_for_output_option () {
> 		if ...
> 		then
> 			meld_has_output_option=true
> 		else
> 			meld_has_output_option=false
> 		fi
> 	}
> 
> 	merge_cmd () {
> 		if test -z "${meld_has_output_option:+set}"
> 		then
> 			check_meld_for_output_option
> 		fi
> 
> 		if test "$meld_has_output_option" = true
> 		then
> 			...
> 
> 
> [...]
> > +	# Filter meld --version to contain numbers and dots only
> > +	meld="$(meld --version 2>/dev/null | sed -e 's/[^0-9.]\+//g')"
> 
> \+ is not a BRE.  If parsing version numbers seems like the right
> thing to do, maybe "tr -cd 0-9."?
> 
> > +	meld="${meld:-0.0.0}"
> > +
> > +	meld_major="$(expr "$meld" : '\([0-9]\{1,\}\)' || echo 0)"
> > +	meld_minor="$(expr "$meld" : '[0-9]\{1,\}\.\([0-9]\{1,\}\)' || echo 0)"
> 
> I think git avoids \{m,n\} ranges where possible (for portability).
> This could be:
> 
> 	meld_major=${meld%%.*}
> 	meld_nonmajor=${meld#${meld_major}.}
> 	meld_minor=${meld_nonmajor%%.*}
> 
> or:
> 
> 	case $meld in
> 	[2-9].* | [1-9][0-9]* | 1.[5-9]* | 1.[1-9][0-9]*)	# >= 1.5.0
> 		meld_has_output_option=true ;;
> 	*)
> 		meld_has_output_option=false ;;
> 	esac
> 
> It's nice how self-contained this can be now that it's in its own
> file.  Thanks.

Right, I was using \{1,\} since that's what CodingStyle said to
use instead of \+ (which I forgot to fixup above as you saw).

The case statement is nice and simple enough to understand.
By doing meld --output /dev/null --help we're relying on
older versions blowing up with --output and --help returning
exit status 0.  That seems pretty reasonable.
The case statement does seem sufficient but just trying
--output and seeing what happens is even simpler.
Your example also uses $merge_tool_path, which I forgot to do,
so I'll be sure to include that too.

I'll wait until tomorrow to see if there are any more comments
and reroll.

Thanks,
-- 
					David

  reply	other threads:[~2011-08-18  9:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-18  7:23 [PATCH 0/4] Refactor git-mergetool--lib.sh David Aguilar
2011-08-18  7:23 ` [PATCH 1/4] difftool--helper: Make style consistent with git David Aguilar
2011-08-18  7:49   ` Sebastian Schuberth
2011-08-18  9:08     ` David Aguilar
2011-08-18 17:31       ` Junio C Hamano
2011-08-18  7:23 ` [PATCH 2/4] mergetool--lib: " David Aguilar
2011-08-18  7:23 ` [PATCH 3/4] mergetool--lib: Refactor tools into separate files David Aguilar
2011-10-09  9:17   ` [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask Jonathan Nieder
2011-10-09 11:43     ` Jonathan Nieder
2011-10-09 18:26       ` David Aguilar
2011-10-09 21:47         ` Jonathan Nieder
2011-10-11  0:00         ` Junio C Hamano
2011-08-18  7:23 ` [PATCH 4/4] mergetools/meld: Use '--output' when available David Aguilar
2011-08-18  8:13   ` Jonathan Nieder
2011-08-18  9:24     ` David Aguilar [this message]
2011-08-19  9:14   ` [PATCH v2 " David Aguilar
2011-08-19 22:58     ` Junio C Hamano
2011-08-18  7:57 ` [PATCH 0/4] Refactor git-mergetool--lib.sh Sebastian Schuberth

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=20110818092403.GB15416@gmail.com \
    --to=davvid@gmail.com \
    --cc=charles@hashpling.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=sschuberth@gmail.com \
    --cc=tanguy+debian@ortolo.eu \
    /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 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 NNTP newsgroup(s).