When I type git difftool
under plain cygwin shell, I just receive benign exit:
~/sb/ws> git difftool
~/sb/ws>
But when I type exactly the same thing under Emacs inferior shell (running the same cygwin bash), I receive the following error:
~/sb/ws> git difftool
git difftool
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "ENU"
are 开发者_开发问答supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
~/sb/ws>
Any idea why this is happening and how to fix this?
(all other git commands, by the way, work perfectly under this Emacs inferior shell, so I can only assume this must be something specific to difftool
)
EDIT (providing variant & version information on the tools involved):
- cygwin-1.7.8-1
- GNU Emacs 23.2.1 (i386-mingw-nt6.1.7600) of 2010-05-08 on G41R2F1
- git version 1.7.4
- Windows 7 Ultimate 64-bit
you're really have wrong LANG, look onto /usr/share/locale for list of available locales..
But really question is - why're using git directly in Emacs, when it has several good git modes, and magit - the best between them? Why not perform all tasks using Emacs?
P.S. I have an article about Emacs + Git...
Update 6 years later (2017)
all other git commands, by the way, work perfectly under this Emacs inferior shell, so I can only assume this must be something specific to
difftool
What is specific to difftool
is that it is still (but not for long) written in perl: git-difftool.perl
But that will change soon with Git 2.12 (Q1 2017).
That means difftool
should run under Emacs just fine, not being bothered with Perl anymore.
See commit 03831ef and commit 019678d (19 Jan 2017) by Johannes Schindelin (dscho
).
difftool
: implement the functionality in the builtinThe motivation for converting the
difftool
is that Perl scripts are not at all native on Windows, and thatgit difftool
therefore is pretty slow on that platform, when there is no good reason for it to be slow.In addition, Perl does not really have access to Git's internals.
That means that any script will always have to jump through unnecessary hoops, and it will often need to perform unnecessary work (e.g. when reading the entire config every timegit config
is called to query a single config value).The current version of the builtin difftool does not, however, make full use of the internals but instead chooses to spawn a couple of Git processes, still, to make for an easier conversion. There remains a lot of room for improvement, left later.
Note: to play it safe, the original
difftool
is still called unless the config settingdifftool.useBuiltin
is set totrue
.The reason: this new, experimental, builtin
difftool
was shipped as part of Git for Windows v2.11.0, to allow for easier large-scale testing, but of course as an opt-in feature.The speedup is actually more noticable on Linux than on Windows: a quick test shows that
t7800-difftool.sh
runs/
- in (2.183s/0.052s/0.108s) (real/user/sys) in a Linux VM, down from (6.529s/3.112s/0.644s), while
- on Windows, it is (36.064s/2.730s/7.194s), down from (47.637s/2.407s/6.863s).
The culprit is most likely the overhead incurred from still having to shell out to
mergetool-lib.sh
anddifftool--helper.sh
.Still, it is an improvement.
精彩评论