Git print files in Windows Format - windows

The most common use case I deal with git is to checkout file or remove or add file from Windows Command prompt.
I don't intend to use fancy gui tools. I like to work with keyboard and command prompt as much as possible.
So whenever I ask git status or any other report, git prints the file name like this
error: The following untracked working tree files would be overwritten by merge:
Tasks/Test/MyTest.js
The problem is, I can't just copy paste that text and use git checkout or git add anything. Since Windows can't understand / it expects you to give with \
Is there anyway git can print the info in Windows format or Windows can accept the *nix format [del Tasks/Test/MyTest.js]

I just tested Git using the Command Prompt and I had no trouble running git add on a file path which included forward slashes, so I don't see your problem as being reproducible.
Another option for you to consider is to use the Git Bash command line tool which ships with the Windows download of Git. The bash is a window, similar in appearance to the Command Prompt, but more powerful. On my Windows setup the Git Bash program is located here:
C:\Program Files\Git\git-bash.exe
The Git Bash tool does not make a distinction between / and \ in the path. Since either will work, you only need to copy the output you want, which is also easy and straightforward.
And good for you for sticking to command line Git. I believe you will become a stronger Git user by learning the nuts and bolts first on the command line.

Related

Can't use git add with --patch option

I recently updated Git to version 2.7.2.windows.1 (I am running Windows 7 64-bit). Since the update, I have been unable to run git add with the -p option on files within a certain directory (or its subdirectories) whose name is _ (an underscore).
git status correctly reports that my file has changes:
PS C:\Users\Carl\www\dl> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: _/php/class.Menu.php
And I can add the entire file with a simple git add, or by specifying the file by name. But if I try to include the -p or --patch option (both variations produce the same results), Git reports that there are no changes:
PS C:\Users\Carl\www\dl> git add -p .\_\php\class.Menu.php
No changes.
This only happens for files within the _ directory, but it doesn't matter whether I cd into that directory to run the git add command without having to explicitly specify a path with an underscore in it; it still doesn't work:
PS C:\Users\Carl\www\dl\_\php> git add -p .\class.Menu.php
No changes.
I had initially thought this problem was related to a similar one I encountered recently on files within the _ directory, which I asked about here. However, that problem appears to have been related to Posix path conversion in MinGW, whereas this problem occurs whether I use Git Bash, Windows PowerShell, or cmd.exe.
As I said in that previous question, I believe underscores to be valid in file/directory names. Additionally, I am not the owner of the project so I cannot rename the directory or move the file.
Is this a bug in Git? Are there any additional steps I can take to determine what the underlying issue is?
Well, I was able to reproduce this, and seems that it is the same POSIX-to-Windows path conversion. ProcessMonitor shows that git (actually, perl run by git) looks for a file C:\Program Files\Git\php\class.Menu.php.
To work this around (at least, that worked for me), according to documentation, you can set the environment variable MSYS_NO_PATHCONV temporarily, like so (in git bash):
MSYS_NO_PATHCONV=1 git add -p _/php/class.Menu.php
(I don't know how to set env variables in windows' cmd/powershell, but that should be possible, too.)
You shouldn't enable MSYS_NO_PATHCONV globally/permanently (e.g. using export in git bash or modifying windows' user/system environment variables in system settings), because that can lead to unwanted effects, and it'll probably break much more things than it'll fix (see this SO comment). Actually, git-windows folks warn against even temporary enabling MSYS_NO_PATHCONV.
Having said that, I'm starting to think that OP's problem is a git-for-windows bug and should be reported as such (might have something to do with the fact that git-add is a binary, but git-add--interactive is a perl script).
Another listed workaround is to double the first slash, like git add -p _//php/class.Menu.php (or does that mean the parameter must start with a double slash?), but that doesn't seem to work due to complex intermediate path conversions, that happen between the invocation of git add and the real file access.
I'd try without that .. Also I've never passed a filename to git add -p. I just make my change and run that as is. I would also check to make sure any changes you're making are in fact being applied to that specific file, and the file is being touched.

Git Bash how to show info about repo files like in Git Shell

I`m working with Git Bash on Windows. But before, I was working with Git Shell (from github). In Git Shell was this really awesome thing, See the image below:
In Git Shell, I do not need to use git status to see how many untracked, changed or deleted file I had. Git Shell shows that information after any command.
How can I do this for Git Bash (on Windows)?
You can simply manipulate the PS1 variable, something like this might help you:
$ PS1="$PS1 [`git diff --shortstat`]> "
The result should be something like this:
rlegendi#localhost /.../gitrepo (master)
[ 1 file changed, 3 insertions(+)] >
So basically you have to add this like to your profile file (either at the Git installation directory typically under c:\Program Files (x86)\Git\etc or in your home directory). That way you can create a bit nicer version.
Take a look on PROMPT_COMMAND and different git diff switches (like --numstat, etc.).

Which Windows Shell command will print a file content on the standard output (like cat in Linux)?

Which Windows Shell command will print a file content on the standard output (like cat in Linux) ?
With Google, Stackoverflow, etc, I just could not find a solution, but I am sure, there is an easy one.
The command is: type <filename>
However, if you want to Unix-fy your Windows shell there are Win32 ports of most of the command Unix style commands.
This is kinda hacky but I did this...
Download Git Bash for Windows. This is very useful to open a linux style command prompt on windows.
Then, create a new git repository and add the file you wish to show to the git repo. Then you can git show.
Let's say you have testFile.txt that you wish to show and it is located at "C:\Users\username\Desktop\FolderWhereFileIs"
cd "/c/Users/username/Desktop/FolderWhereFileIs/"
git add -A
git commit -m "Commit with all files"
git show testFile.txt

Want to download a Git repository, what do I need (windows machine)?

I want to download this open source application, and they are using Git. What do I need to download the code base?
Update
How do I change the working directory when I am using Git Bash? (I want to download the repo at a certain directory, using pwd tells me I will be downloading the repo where I don't want it.
Download Git on Msys. Then:
git clone git://project.url.here
Install mysysgit. (Same as Greg Hewgill's answer.)
Install Tortoisegit. (Tortoisegit requires mysysgit or something similiar like Cygwin.)
After TortoiseGit is installed, right-click on a folder, select Git Clone..., then enter the Url of the repository, then click Ok.
This answer is not any better than just installing mysysgit, but you can avoid the dreaded command line. :)
I don't want to start a "What's the best unix command line under Windows" war, but have you thought of Cygwin? Git is in the Cygwin package repository.
And you get a lot of beneficial side-effects! (:-)
To change working directory in GitMSYS's Git Bash you can just use cd
cd /path/do/directory
Note that:
Directory separators use the forward-slash (/) instead of backslash.
Drives are specified with a lower case letter and no colon, e.g. "C:\stuff" should be represented with "/c/stuff".
Spaces can be escaped with a backslash (\)
Command line completion is your friend. Press TAB at anytime to expand stuff, including Git options, branches, tags, and directories.
Also, you can right click in Windows Explorer on a directory and "Git Bash here".

How can I set up an editor to work with Git on Windows?

I'm trying out Git on Windows. I got to the point of trying "git commit" and I got this error:
Terminal is dumb but no VISUAL nor
EDITOR defined. Please supply the
message using either -m or -F option.
So I figured out I need to have an environment variable called EDITOR. No problem. I set it to point to Notepad. That worked, almost. The default commit message opens in Notepad. But Notepad doesn't support bare line feeds. I went out and got Notepad++, but I can't figure out how to get Notepad++ set up as the %EDITOR% in such a way that it works with Git as expected.
I'm not married to Notepad++. At this point I don't mind what editor I use. I just want to be able to type commit messages in an editor rather than the command line (with -m).
Those of you using Git on Windows: What tool do you use to edit your commit messages, and what did you have to do to make it work?
Update September 2015 (6 years later)
The last release of git-for-Windows (2.5.3) now includes:
By configuring git config core.editor notepad, users can now use notepad.exe as their default editor.
Configuring git config format.commitMessageColumns 72 will be picked up by the notepad wrapper and line-wrap the commit message after the user edits it.
See commit 69b301b by Johannes Schindelin (dscho).
And Git 2.16 (Q1 2018) will show a message to tell the user that it is waiting for the user to finish editing when spawning an editor, in case the editor
opens to a hidden window or somewhere obscure and the user gets
lost.
See commit abfb04d (07 Dec 2017), and commit a64f213 (29 Nov 2017) by Lars Schneider (larsxschneider).
Helped-by: Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 0c69a13, 19 Dec 2017)
launch_editor(): indicate that Git waits for user input
When a graphical GIT_EDITOR is spawned by a Git command that opens
and waits for user input (e.g. "git rebase -i"), then the editor window
might be obscured by other windows.
The user might be left staring at
the original Git terminal window without even realizing that s/he needs
to interact with another window before Git can proceed. To this user Git
appears hanging.
Print a message that Git is waiting for editor input in the original
terminal and get rid of it when the editor returns, if the terminal
supports erasing the last line
Original answer
I just tested it with git version 1.6.2.msysgit.0.186.gf7512 and Notepad++5.3.1
I prefer to not have to set an EDITOR variable, so I tried:
git config --global core.editor "\"c:\Program Files\Notepad++\notepad++.exe\""
# or
git config --global core.editor "\"c:\Program Files\Notepad++\notepad++.exe\" %*"
That always gives:
C:\prog\git>git config --global --edit
"c:\Program Files\Notepad++\notepad++.exe" %*: c:\Program Files\Notepad++\notepad++.exe: command not found
error: There was a problem with the editor '"c:\Program Files\Notepad++\notepad++.exe" %*'.
If I define a npp.bat including:
"c:\Program Files\Notepad++\notepad++.exe" %*
and I type:
C:\prog\git>git config --global core.editor C:\prog\git\npp.bat
It just works from the DOS session, but not from the git shell.
(not that with the core.editor configuration mechanism, a script with "start /WAIT..." in it would not work, but only open a new DOS window)
Bennett's answer mentions the possibility to avoid adding a script, but to reference directly the program itself between simple quotes. Note the direction of the slashes! Use / NOT \ to separate folders in the path name!
git config --global core.editor \
"'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
Or if you are in a 64 bit system:
git config --global core.editor \
"'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
But I prefer using a script (see below): that way I can play with different paths or different options without having to register again a git config.
The actual solution (with a script) was to realize that:
what you refer to in the config file is actually a shell (/bin/sh) script, not a DOS script.
So what does work is:
C:\prog\git>git config --global core.editor C:/prog/git/npp.bat
with C:/prog/git/npp.bat:
#!/bin/sh
"c:/Program Files/Notepad++/notepad++.exe" -multiInst "$*"
or
#!/bin/sh
"c:/Program Files/Notepad++/notepad++.exe" -multiInst -notabbar -nosession -noPlugin "$*"
With that setting, I can do 'git config --global --edit' from DOS or Git Shell, or I can do 'git rebase -i ...' from DOS or Git Shell.
Bot commands will trigger a new instance of notepad++ (hence the -multiInst' option), and wait for that instance to be closed before going on.
Note that I use only '/', not \'. And I installed msysgit using option 2. (Add the git\bin directory to the PATH environment variable, but without overriding some built-in windows tools)
The fact that the notepad++ wrapper is called .bat is not important.
It would be better to name it 'npp.sh' and to put it in the [git]\cmd directory though (or in any directory referenced by your PATH environment variable).
See also:
How do I view ‘git diff’ output with visual diff program? for the general theory
How do I setup DiffMerge with msysgit / gitk? for another example of external tool (DiffMerge, and WinMerge)
lightfire228 adds in the comments:
For anyone having an issue where N++ just opens a blank file, and git doesn't take your commit message, see "Aborting commit due to empty message": change your .bat or .sh file to say:
"<path-to-n++" .git/COMMIT_EDITMSG -<arguments>.
That will tell notepad++ to open the temp commit file, rather than a blank new one.
Building on Darren's answer, to use Notepad++ you can simply do this (all on one line):
git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
Obviously, the C:/Program Files/Notepad++/notepad++.exe part should be the path to the Notepad++ executable on your system. For example, it might be C:/Program Files (x86)/Notepad++/notepad++.exe.
It works like a charm for me.
Article How to set Notepad++ as the default Git editor for commits instead of Vim explains parameters of the command.
Anyway, I've just been playing around with this and found the following to work nicely for me:
git config --global core.editor "'C:/Program Files/TextPad 5/TextPad.exe' -m"
I don't think CMD likes single-quotes so you must use double quotes "to specify the space embedded string argument".
Cygwin (which I believe is the underlying platform for Git's Bash) on the other hand likes both ' and "; you can specify a CMD-like paths, using / instead of \, so long as the string is quoted i.e. in this instance, using single-quotes.
The -m overrides/indicates the use of multiple editors and there is no need for a %* tacked on the end.
Edit: After updating to Vim 7.3, I've come to the conclusion that the cleanest and easiest way to do this is:
Add Vim's main folder to your path (right click on My Computer → Properties → Advanced → Environment Variables)
Run this:
git config --global core.editor "gvim --nofork '%*'"
If you do it this way, then I am fairly sure it will work with Cygwin as well.
Original answer:
Even with a couple of Vim-related answers, I was having trouble getting this to work with gVim under Windows (while not using a batch file or %EDITOR% or Cygwin).
What I eventually arrived at is nice and clean, and draws from a few of the solutions here:
git config --global core.editor \
"'C:/Program Files/Vim/vim72/gvim.exe' --nofork '%*'"
One gotcha that took me a while is these are not the Windows-style backslashes. They are normal forward slashes.
Notepad++ works just fine, although I choose to stick with Notepad, -m, or even sometimes the built-in "edit."
The problem you are encountering using Notepad++ is related to how Git is launching the editor executable. My solution to this is to set environment variable EDITOR to a batch file, rather than the actual editor executable, that does the following:
start /WAIT "E:\PortableApps\Notepad++Portable\Notepad++Portable.exe" %*
/WAIT tells the command line session to halt until the application exits, thus you will be able to edit to your heart's content while Git happily waits for you. %* passes all arguments to the batch file through to Notepad++.
C:\src> echo %EDITOR%
C:\tools\runeditor.bat
For Atom you can do
git config --global core.editor "atom --wait"
and similar for Visual Studio Code
git config --global core.editor "code --wait"
which will open up an Atom or Visual Studio Code window for you to commit through,
or for Sublime Text:
git config --global core.editor "subl -n -w"
WordPad!
I'm happy using Vim, but since I'm trying to introduce Git to the company I wanted something that we'd all have, and found that WordPad seems to work okay (i.e. Git does wait until you're finished editing and close the window).
git config core.editor '"C:\Program Files\Windows NT\Accessories\wordpad.exe"'
That's using Git Bash on msysgit; I've not tried from the Windows command prompt (if that makes any difference).
I also use Cygwin on Windows, but with gVim (as opposed to the terminal-based Vim).
To make this work, I have done the following:
Created a one-line batch file (named git_editor.bat) which contains the following:
"C:/Program Files/Vim/vim72/gvim.exe" --nofork "%*"
Placed git_editor.bat on in my PATH.
Set GIT_EDITOR=git_editor.bat
With this done, git commit, etc. will correctly invoke the gVim executable.
NOTE 1: The --nofork option to gVim ensures that it blocks until the commit message has been written.
NOTE 2: The quotes around the path to gVim is required if you have spaces in the path.
NOTE 3: The quotes around "%*" are needed just in case Git passes a file path with spaces.
Edit .gitconfig file in c:\Users\YourUser folder and add:
[core]
editor = 'C:\\Program files\\path\\to\\editor.exe'
Thanks to the Stack Overflow community ... and a little research I was able to get my favorite editor, EditPad Pro, to work as the core editor with msysgit 1.7.5.GIT and TortoiseGit v1.7.3.0 over Windows XP SP3...
Following the advice above, I added the path to a Bash script for the code editor...
git config --global core.editor c:/msysgit/cmd/epp.sh
However, after several failed attempts at the above mentioned solutions ... I was finally able to get this working. Per EditPad Pro's documentation, adding the '/newinstance' flag would allow the shell to wait for the editor input...
The '/newinstance' flag was the key in my case...
#!/bin/sh
"C:/Program Files/JGsoft/EditPadPro6/EditPadPro.exe" //newinstance "$*"
This is the one symptom of greater issues. Notably that you have something setting TERM=dumb. Other things that don't work properly are the less command which says you don't have a fully functional terminal.
It seems like this is most commonly caused by having TERM set to something in your global Windows environment variables. For me, the issue came up when I installed Strawberry Perl some information about this is on the msysgit bug for this problem as well as several solutions.
The first solution is to fix it in your ~/.bashrc by adding:
export TERM=msys
You can do this from the Git Bash prompt like so:
echo "export TERM=msys" >> ~/.bashrc
The other solution, which ultimately is what I did because I don't care about Strawberry Perl's reasons for adding TERM=dumb to my environment settings, is to go and remove the TERM=dumb as directed in this comment on the msysgit bug report.
Control
Panel/System/Advanced/Environment
Variables... (or similar, depending on
your version of Windows) is where
sticky environment variables are set
on Windows. By default, TERM is not
set. If TERM is set in there, then you
(or one of the programs you have
installed - e.g. Strawberry Perl) has
set it. Delete that setting, and you
should be fine.
Similarly if you use Strawberry Perl and care about the CPAN client or something like that, you can leave the TERM=dumb alone and use unset TERM in your ~/.bashrc file which will have a similar effect to setting an explicit term as above.
Of course, all the other solutions are correct in that you can use git config --global core.editor $MYFAVORITEEDITOR to make sure that Git uses your favorite editor when it needs to launch one for you.
Vim/gVim works well for me.
>echo %EDITOR%
c:\Vim\Vim71\vim.exe
I needed to do both of the following to get Git to launch Notepad++ in Windows:
Add the following to .gitconfig:
editor = 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin
Modify the shortcut to launch the Git Bash shell to run as administrator, and then use that to launch the Git Bash shell. I was guessing that the context menu entry "Git Bash here" was not launching Notepad++ with the required permissions.
After doing both of the above, it worked.
I had PortableGit 1.6 working fine, but after upgrading to the PortableGit 1.7 Windows release, I had problems. Some of the Git commands opens up the Notepad++.exe fine, but some don't, especially Git rebase behaves differently.
The problem is some commands run the Windows cmd process and some use the Unix cmd process. I want to give startup attributes to Notepad++ editor, so I need to have a customized script. My solution is this.
Create a script to run an appropriate text editor. The script looks weird, but it handles both the Windows and Unix variation.
c:/PortableGit/cmd/git-editor.bat
#!/bin/sh
# Open a new instance
function doUnix() {
"c:\program files\notepad++\notepad++.exe" -multiInst -nosession -notabbar $*
exit
}
doUnix $*
:WINCALL
"c:\program files\notepad++\notepad++.exe" -multiInst -nosession -notabbar %*
Set the global core.editor variable
The script was saved to git/cmd folder, so it's already in a gitconsole path. This is mandatory as a full path may not work properly.
git config --global core.editor "git-editor.bat"
Now I can run the git commit -a and git rebase -i master commands. Give it a try if you have problems in the Git Windows tool.
I use Git on multiple platforms, and I like to use the same Git settings on all of them. (In fact, I have all my configuration files under release control with Git, and put a Git repository clone on each machine.) The solution I came up with is this:
I set my editor to giteditor
git config --global core.editor giteditor
Then I create a symbolic link called giteditor which is in my PATH. (I have a personal bin directory, but anywhere in the PATH works.) That link points to my current editor of choice. On different machines and different platforms, I use different editors, so this means that I don't have to change my universal Git configuration (.gitconfig), just the link that giteditor points to.
Symbolic links are handled by every operating system I know of, though they may use different commands. For Linux, you use ln -s. For Windows, you use the cmd built-in mklink. They have different syntaxes (which you should look up), but it all works the same way, really.
Based on VonC's suggestion, this worked for me (was driving me crazy):
git config --global core.editor "'C:/Program Files (x86)/Sublime Text 3/subl.exe' -wait"
Omitting -wait can cause problems, especially if you are working with Gerrit and change ids that have to be manually copied to the bottom of your commit message.
I use Cygwin on Windows, so I use:
export EDITOR="emacs -nw"
The -nw is for no-windows, i.e. tell Emacs not to try and use X Window.
The Emacs keybindings don't work for me from a Windows shell, so I would only use this from a Cygwin shell... (rxvt is recommended.)
This is my setup to use Geany as an editor for Git:
git config --global core.editor C:/path/to/geany.bat
with the following content in geany.bat:
#!/bin/sh
"C:\Program Files\Geany\bin\Geany.exe" --new-instance "$*"
It works in both a DOS console and msysgit.
Say you want to configure VsCode to be your editor.
Do the following:
Add the following lines to your .gitconfig file:
The default location of .gitconfig file is C:\Users\USER_NAME\.gitconfig
[core]
editor = code -w -n
[diff]
tool = vscode
[difftool "vscode"]
cmd = code -w -n --diff $LOCAL $REMOTE
[merge]
tool = vscode
[mergetool "vscode"]
cmd = code -w -n $MERGED
NOTE:
-w is mandatory, and tells git to wait for vscode to load.
-n is optional, and tells git to open vscode in a new-window.
In case you want to configure a custom path to the editor in Windows:
You need to replace the word code with Path to '.exe' of VsCode.
For example:
[core]
editor = "'C:/Users/Tal/AppData/Local/Programs/Microsoft VS Code/Code.exe'" -w -n
[diff]
tool = vscode
[difftool "vscode"]
cmd = "'C:/Users/Tal/AppData/Local/Programs/Microsoft VS Code/Code.exe'" -w -n --diff $LOCAL $REMOTE
[merge]
tool = vscode
[mergetool "vscode"]
cmd = "'C:/Users/Tal/AppData/Local/Programs/Microsoft VS Code/Code.exe'" -w -n $MERGED
Note:
You need to surround the path with single-quotes ''.
The slashes in the path should be forward-slashes /.
Or another example:
[core]
editor = \"C:\\Users\\Tal\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" -w -n
[diff]
tool = vscode
[difftool "vscode"]
cmd = \"C:\\Users\\Tal\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" -w -n --diff $LOCAL $REMOTE
[merge]
tool = vscode
[mergetool "vscode"]
cmd = \"C:\\Users\\Tal\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" -w -n $MERGED
UPDATE:
VsCode supports now "3-way merges"!
The update was done in versions 1.69.0 and 1.70.0.
So now you can enable the VsCode "mergetool" to view 3-way merges.
To do so, you need to update the line:
[mergetool "vscode"]
cmd = code -w -n $MERGED
with the new line:
[mergetool "vscode"]
cmd = code -w -n --merge $REMOTE $LOCAL $BASE $MERGED
It seems as if Git won't find the editor if there are spaces in the path. So you will have to put the batch file mentioned in Patrick's answer into a non-whitespace path.
I prefer to use Emacs. Getting it set up can be a little tricky.
Download Emacs and unpack it somewhere like c:\emacs.
Run c:\emacs\bin\addpm.exe. You need to right-click and "Run as Administrator" if you are using Windows Vista or above. This will put the executables in your path.
Add (server-start) somewhere in your .emacs file. See the Emacs Windows FAQ for advice on where to put your .emacs file.
git config --global core.editor emacsclientw
Git will now open files within an existing Emacs process. You will have to run that existing process manually from c:\emacs\bin\runemacs.exe.
I managed to get the environment version working by setting the EDITOR variable using quotes and /:
EDITOR="c:/Program Files (x86)/Notepad++/notepad++.exe"
I've had difficulty getting Git to cooperate with WordPad, Komodo Edit and pretty much every other editor I give it. Most open for editing, but Git clearly doesn't wait for the save/close to happen.
As a crutch, I've just been doing i.e.
git commit -m "Fixed the LoadAll method"
to keep things moving. It tends to keep my commit messages a little shorter than they probably should be, but clearly there's some work to be done on the Windows version of Git.
The GitGUI also isn't that bad. It takes a little bit of orientation, but after that, it works fairly well.
I've just had the same problem and found a different solution. I was getting
error: There was a problem with the editor 'ec'
I've got VISUAL=ec, and a batch file called ec.bat on my path that contains one line:
c:\emacs\emacs-23.1\bin\emacsclient.exe %*
This lets me edit files from the command line with ec <filename>, and having VISUAL set means most unixy programs pick it up too. Git seems to search the path differently to my other commands though - when I looked at a git commit in Process Monitor I saw it look in every folder on the path for ec and for ec.exe, but not for ec.bat. I added another environment variable (GIT_EDITOR=ec.bat) and all was fine.
I'm using GitHub for Windows which is a nice visual option. But I also prefer the command line, so to make it work when I open a repository in a Git shell I just set the following:
git config --global core.editor vim
which works great.
This works for PowerShell and cmder 1.2 (when used with PowerShell). In file ~/.gitconfig:
[core]
editor = 'c:/program files/sublime text 3/subl.exe' -w
How can I make Sublime Text the default editor for Git?
I found a a beautifully simple solution posted here - although there may be a mistake in the path in which you have to copy over the "subl" file given by the author.
I am running Windows 7 x64, and I had to put the "subl" file in my /Git/cmd/ folder to make it work.
It works like a charm, though.
Atom and Windows 10
I right clicked the Atom icon at the desktop and clicked on properties.
Copied the "Start in" location path
Looked over there with Windows Explorer and found "atom.exe".
I typed this in Git Bash:
git config --global core.editor C:/Users/YOURNAMEUSER/AppData/Local/atom/app-1.7.4/atom.exe"
Note: I changed all \ for / . I created a .bashrc at my home directory and used / to set my home directory and it worked, so I assumed / will be the way to go.
atom-editor git git-bash windows-10
to add sublime git config --global core.editor "'C:\Program Files\Sublime Text 3\sublime_text.exe'"
I solved a similar issue using GIT_EDITOR variable and notepad2 as editor.
Solution 1: Set the environment variable GIT_EDITOR to C:/tools/notepad2.exe. This works nicely, but git complains if the commit message has non-ASCII characters.
Solution 2: Set GIT_EDITOR to C:/tools/notepad2.exe //utf8. Notice the double slash in front of the program switch. BTW: -utf8 would have worked as well.

Resources