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 builtin
The motivation for converting the difftool is that Perl scripts are not at all native on Windows, and that git 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 time git 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 setting difftool.useBuiltin is set to true.
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 and difftool--helper.sh.
Still, it is an improvement.
Related
I'm just getting started trying to use command line and gitbash, and I've run into some basic issues.
As I understand it from the lesson I'm trying to go through online, I can run gitbash on windows instead of standard command line I would find on Mac and Linux(?)
The blurb about it was:
"WINDOWS USERS: You might want to jump ahead to the Installations Assignment and use the "Git Bash" application you'll install there instead of using the default Command Prompt. That way you can be sure all the commands will be the same."
So I downloaded Gitbash via Railsinstaller but the first command, man/man ls, gives me this error.
Am I misunderstanding the function of Gitbash? Do I need to install something to add on or something else entirely?
Unfortunately, one of the notable faults of Git Bash is that it does not ship with a man command, so no, you are not misunderstanding anything. If you try to ls or cd or grep you'll see that it works fine.
Without going into too much background, Git Bash is a shell environment on Windows that emulates standard POSIX terminal behavior and makes some common Linux tools available. I'm not personally prone to the reasoning behind this decision, but I just double-checked and man (and man-db, etc.) are available in the ecosystem behind the tool that Git Bash derives from. If you want to fight for it, you might want to open an issue on the Git for Windows GH repository; Johannes Schindelin is the lead maintainer there and is very active.
I installed Git For Windows 2.7.2 a few days ago. Now I have some problems with using optional tools Git For Windows provides from cmd.exe. In the previous version of Git For Windows(or say msysgit), I could configure these tools by modifying Git/etc/git-completion.bash. For example:
alias ls='ls --show-control-chars --color=auto'
I used this way to make ls display file names that contained Chinese characters normally. Now it seems this way doesn't work. In fact there is no git-completion.bash under Git/etc/. There is a git-completion.bash under the folder Git/mingw64/share/git/completion. I tried to copy it to Git/etc and add the alias above, which didn't work either. These tools only works fine in Git Bash. So how should I configure these tools together with git to use them from cmd.exe?
This answer explains why you no longer have this functionality. In short, msysgit provided a unix shell emulator, mingw. Git for Windows is git compiled in a Windows environment.
Therefore, ls is simply an alias for dir in a Windows shell, not mingw's ls. If you want to create some Windows aliases, you can use doskey. Here's an answer for that.
Alternatively, I would suggest that you just start using PowerShell, where you'll be able to set up the $profile variable with some powerful commands like these.
I understand that console applications using git bash invoke sh.exe but I wonder how they continue to use sh.
I see on console apps often you do a sh.exe --login. I would guess this creates a session somewhere and I would presume that the console application would execute commands against it somehow?
Essentially I switched from UNIX to Windows. I have tried a lot of console apps (best being console2 and just git-bash) but they still do not work for me well.
Ia m annoyed enough that I fancy trying to programming a simple shell in Java. (I am a Java developer by trade.)
Any help would be great thanks to understand this, looking but searchs with console or git-bash in google generate so much random noise.
If you are using one of the various Unix shells ported to Windows, you should be aware that most of these shells use some heuristic to make Windows look like Unix, either to build a compatibility layout or for user convenience.
For instance, the git command is probably stored in a git.exe file but your shell scripts imported from your Unix workstation all say git so the shell will lookup git.exe if it does not find git.
Nobe of these heuristics works perfectly, so you have to expect regular inconsistencies and disagreements, especially if your are mixing several Unix ports together.
As for the meaning of --login, it is synonymous to -l and its main effect is to decide which initialization files are read by bash on startup`
-l Make bash act as if it had been invoked as a login shell (see
INVOCATION below).
Problem:
git add -p seems unusable in either emacs shell or eshell
magit (a frequently suggested alternative to using git from the shell in emacs) sucks balls on Windows (it's horrendously slow.)
Keeping a cygwin window open and using that for git add -p and then going back and forth between that and emacs is doable, but more than a little annoying.
Is there any way that under Microsoft Windows I can get either git add -p to work well in shell or eshell or alternatively get magit to be somewhat usable?
If magit is slow, that probably indicates problems with your windows git client?
I would look into that first and foremost (because git add -p really doesn't hold a candle to magit's interface, IMO).
What are the exact tools (and versions thereof) which you are using?
You should definitely check the magit issue tracker to see if there are known reasons why magit might be slow.
Have you tried:
% EDITOR=emacsclient git add -e <files>
and then using the diff-mode commands in your running emacs to interactively edit the hunks of the patch?
Then you will be able to split hunks within the patch at any particular line with diff-split-hunk and remove hunks entirely with diff-hunk-kill (and of course these commands are bound to shorter key sequences for quick interactive use). When you are done editting the patch, use C-x # to save it and quit the emacsclient session (so that you can go back to your shell).
(emacsclient, if you are not familiar with it, is a program that will let you open files in an already-running emacs, as long as the latter has started up a server for emacsclient to connect to; see the M-x describe-function server-start)
Note that you will probably want to customize how emacsclient interacts with git a little bit; for example, see these answers: Using ediff as git mergetool and How to set the exit status for emacsclient.
I'm using msysgit 1.7.7.1 on Windows. I get an error when using git diff. What is causing this? Is there no diff tool included in msysgit? What should I do?
WARNING: terminal is not fully functional
If you are having issues in cmd.exe, for instance, see the warning here:
Then simply set your environment variables and include TERM=msys. After that, each time you open a cmd.exe, your variable will be set correctly.
NOW YOU MUST RESTART YOUR SHELL (CMD.EXE). Just run a new one. And from there, you should have no more issues. Again:
For Git Bash, this can be fixed by adding the following line to ~/.bashrc:
export TERM=cygwin
-or-
export TERM=msys
The first seems to be the original by git for windows, the second a popular known form to "heal" as well.
The problem can be caused if some other program (like for example Strawberry Perl) sets the TERM system environment variables.
http://code.google.com/p/msysgit/issues/detail?id=184
Above answers was not fully worked for me, so I did:
Add
export TERM=msys
to "[githome]/etc/profile" at the top but it made changes only for git bash. Then I added
#set TERM=msys
to "[githome]/cmd/git.cmd" after #setlocal (I installed only git run from command line). May be this decision not truly good but it works for me and there are not any terminal warnings. (I use git version 1.7.10.msysgit.1).
The answer can be found here, in which the author of the solution claims that:
the environment variable TERM was set to dumb
that was instead of
TERM=cygwin
You can change that to
TERM=msys
to solve the problem at hand.
I work in powershell and I have the git executable directly in my path.
None of the suggested answers worked, but I found a solution that works for me.
I added a line in my powershell profile:
$env:TERM="msys"
Which fixed the problem for me.
A quick & dirty solution in my case turned out to be to use the --no-pager option.
By default, some git commands (like log) will use a pager like less if they expect the output to be long. Pagers require things like scrolling text up and down with the arrow keys, which sometimes doesn't work if the assumptions about what kind of terminal you're on are wrong (this is what the "not fully functional" means).
If you know ahead of time that your output will be short, or you just want it to dump output to the terminal and leave the scrolling up to your terminal program, you can override this and not use a pager at all, e.g.:
git --no-pager log
In case someone gets this launching bash from Git Extensions, check the setting for Path to linux tools.... Mine was set to C:\cygwin. Changing it to C:\Program Files (x86)\Git\bin\ fixed it for me. I didn't have to set the TERM variable to launch bash this way.