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.
Related
I often find myself appending --help|less to commands that I am crafting a command in a shell to explore the CLI of the program I am using. What ways are there to accomplish the same thing with fewer key-presses?
For instance, if I wanted to use the new way of switching branches (I don't, I'm stuck in my ways happily doing git checkout -b other_branch) then my history (and thought process) could look like
git change other_branch # Guess what the command should be
git --help|less # Backtrack to where I am confident I know the command and ask for help
git switch --help|less # Gradually build up the command from there
git switch other_branch
For context:
I typically want the pager either to be able to search or because I am working in tmux and activating scrolling takes a few additional, and awkward, key-presses.
I typically use zsh on Ubuntu or Debian.
I typically use arrow up to iterate on my previous command.
Add the following to your .zshrc file:
# Alt-H: Open `man` page of current command.
unalias run-help
autoload -Uz run-help{,-{git,ip,openssl,p4,sudo,svk,svn}}
Then restart your shell.
Now, whenever you're in the middle of typing a command, you can press AltH (^[h) to immediately open the man page for that command. Then, after you quit your pager, Zsh will will automatically restore your command line, so you can finish typing.
I've just upgraded OS from Ubuntu 16.04 to 18.04 and for some reason emacs disappeared.
On reinstalling I've just noticed that running M-x shell then hg diff produces an error message:
WARNING: terminal is not fully functional
- (press RETURN)
I think I may have fixed this by running:
export TERM=xterm
After which I got a very colourful shell experience and no warning on running hg diff
However, its only displaying one page of the hg diff output then pausing with a : at a time now, previously it printed the lot without stopping.
I think this may be acceptable, if I could figure out what key allows me to print the next page of hg diff output, and ideally, what key would allow printing all remaining hg diff output and return me to the shell prompt.
If I hit return I get an additional line at a time, but this is a bit slow and not really ideal.
I think this is maybe a question about xterm shortcut keys? Possibly not emacs specific, but I'm not sure..
shell-mode is line-buffered, meaning the input won't be sent to the underlying process until you enter RET. In this case, the output should be running through a program like less where RET would give you another page instead of a single line.
So, in shell-mode you can use SPC followed by a RET. In term-mode where the default is not line-buffered (to resemble the underlying shell as transparently as possible) a single RET should suffice to give you a new page.
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'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.
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.