git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: David Kastrup <dak@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: [Untested! proposal] git-mergetool.sh: introduce ediff option
Date: Sun, 29 Jul 2007 16:52:32 -0400	[thread overview]
Message-ID: <20070729205232.GA10148@thunk.org> (raw)
In-Reply-To: <85hcnnwblu.fsf@lola.goethe.zz>

On Sun, Jul 29, 2007 at 03:51:34PM +0200, David Kastrup wrote:
> 
> Most actual Emacs users prefer ediff to emerge concerning the
> consolidation of versions.  In general, people habitually using Emacs
> will have this preference reflected in the EDITOR/VISUAL environment
> variables.

Proof, please?  Do you have any polls?  What evidence do you have?
For the past two decades, I have EDITOR set to emacs, but I am not an
ediff fan.  Yes, that's anecdotal evidence, but so are your assertions.

> If such a preference can be found there, ediff will be used/offered in
> preference of emerge (which retains its previous behavior).

Ediff is currently far more confusing for someone who just uses emacs
as an editor.  There are plenty of users who never learned the vi
commands, but who use emacs as a reasonably easy-to-use text editor.
Not everyone who uses emacs is a power-user.....

> In ediff mode, success or failure of the merge will be discerned by
> Emacs either having written or not written the merge buffer; no
> attempt of interpreting the exit code is made.

Sometimes resolving the merge file results in no changes.  So the fact
that ediff is buggy in that it doesn't return an exit code is a real
problem.  We could possibly work around the problem saving and then
checking the modtime --- but only if ediff actually ends up rewriting
the file.

> In order to bypass things like desktop files being loaded, emerge mode
> now passes the "-q" option to Emacs.  This will make it work in more
> situations likely to occur, at the price of excluding possibly
> harmless user customizations with the rest.

But that screws over users who want their customizations, but who
don't use the desktop package.  (And I have a news flash for you; the
desktop package is *not* include as part of emacs21.  It's not part of
Debian's emacs21 package, version 21.4.)  So do not believe your claim
that emacs's desktop package is commonly used.   

Probably a better choice is a config parameter which allows users to
specify a set of options to be passed to emacs when git fires up an
emacs program.  That would allow some people to specfy --no-desktop if
they are using a new enough emacs program that supports it.  It would
also allow users to use other emacs command-line options that they
might like, i.e., -nw, or --title, etc.

> +	ediff)
> +	    case "${EDITOR:-${VISUAL:-emacs}}" in
> +		*/emacs*|*/gnuclient*|*/xemacs*)
> +		    emacs_candidate="${EDITOR:-${VISUAL:-emacs}}";;
> +		*)
> +		    emacs_candidate=emacs;;
> +	    esac
> +	    if base_present ; then
> +		${emacs_candidate} --eval "(ediff-merge-files-with-ancestor (pop command-line-args-left) (pop command-line-args-left) (pop command-line-args-left) nil (pop-command-line-args-left))" "$LOCAL" "$REMOTE" "$BASE" "$path"

... and this will blow up if EMACS is set to emacsclient, and emacs
version is 21.  (And BTW, Debian stable and the current Ubuntu, Edgy
Eft, are still shipping emacs21.  So are a number of current major
distro's.  So if you think the vast majority of users are using
emacs22, you are either on drugs, and have a very skewed view of what
are "normal" emacs users.)

There is a reason why git-mergetool currently hardcodes the use of
"emacs", instead of just blindly using the value of $EDITOR or
$VISUAL.  So what you're doing here in your patch is completely
busted.  If you insist on using emacs_candidate, we need to run emacs
--version and parse the output, and only using the value of EMACS or
VISUAL if the major version number of emacs is at least 22.

(It would probably be a good idea to do this once and cache the
result, so we don't have to repeatedly for each file that git
mergetool needs to process.)

> -    if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
> -        merge_tool_candidates="$merge_tool_candidates emerge"
> -    fi
> +    case "${EDITOR:-${VISUAL}}" in
> +	*/emacs*|*/gnuclient*|*/xemacs*)
> +            merge_tool_candidates="$merge_tool_candidates ediff"
> +    esac

Changing the default from emerge to ediff is a non-starter, sorry.  If
you really want to use ediff, you can set a config parameter to
explicitly request it.

						- Ted

  reply	other threads:[~2007-07-29 22:49 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-13 22:30 What's in git.git (stable) Junio C Hamano
2007-05-17  0:21 ` Junio C Hamano
2007-05-19  5:24   ` Junio C Hamano
2007-05-23 21:46     ` Junio C Hamano
2007-05-29 10:12       ` Junio C Hamano
2007-06-02 21:09         ` Junio C Hamano
2007-06-07  2:08           ` Junio C Hamano
2007-06-13 20:11             ` Junio C Hamano
2007-06-13 22:31               ` Johannes Schindelin
2007-06-14  7:12                 ` Johannes Sixt
2007-06-21  7:21               ` Junio C Hamano
2007-06-25  9:43                 ` Junio C Hamano
2007-07-02  0:16                   ` Junio C Hamano
2007-07-13  6:06                     ` What's in git.git Junio C Hamano
2007-07-13  6:40                       ` Draft release notes for v1.5.3, as of -rc1 Junio C Hamano
2007-07-13  9:29                         ` Sven Verdoolaege
2007-07-14 14:22                           ` Johannes Schindelin
2007-07-14 18:13                             ` Junio C Hamano
2007-07-15 23:53                               ` Johannes Schindelin
2007-07-13 13:50                         ` Brian Downing
2007-07-13 15:31                           ` Junio C Hamano
2007-07-28  8:47                       ` What's in git.git (stable) Junio C Hamano
2007-07-28  8:56                         ` David Kastrup
2007-07-28  9:02                           ` Junio C Hamano
2007-07-28  9:35                           ` David Kastrup
2007-07-29  3:16                             ` Theodore Tso
2007-07-29  9:05                               ` David Kastrup
2007-07-29 16:40                                 ` Theodore Tso
2007-07-29 11:27                               ` Johannes Schindelin
2007-07-29 13:51                                 ` [Untested! proposal] git-mergetool.sh: introduce ediff option David Kastrup
2007-07-29 20:52                                   ` Theodore Tso [this message]
2007-07-29 23:30                                     ` David Kastrup
2007-07-28 12:28                         ` What's in git.git (stable) Thomas Glanzmann
2007-08-07  6:22                         ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070729205232.GA10148@thunk.org \
    --to=tytso@mit.edu \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).