I use Windows 10 and a while back I changed the default Git editor to Notepad++
Now whenever I execute a command that brings up the editor I can't find any way of saving the message & continuing with the command - I end up having to cancel i.e. CTRL + C
I don't have to have Notepad++ as the editor but I do need to be able to use Git properly.
What I've tried
Restoring the original editor (I wasn't able to find out how)
Finding a similar problem on Stack Overflow
Restoring the original editor (I wasn't able to find out how)
You can try:
cd /path/to/your/repo
git config --unset-all core.editor
git config -l|grep core.editor
(grep is available if you add your <git>/usr/bin to the Windows %PATH%.
<git> is the path where you have installed git)
If that does not work, you might have to remove it for your local and global config:
cd /path/to/your/repo
git config --local --unset-all core.editor
git config --global --unset-all core.editor
git config -l|grep core.editor
Related
Does anyone know how to fix this error? Everything worked fine a few days ago in this same repository. Now that I'm trying to commit new changes, I get this error that I cannot fix. As far as I know, nothing has changed except for some Windows updates from patch Tuesday.
$ git commit
hint: Waiting for your editor to close the file... C:/Program Files/Git/usr/bin/vim.exe: C:/Program: No such file or directory
error: There was a problem with the editor 'C:/Program Files/Git/usr/bin/vim.exe'.
Please supply the message using either -m or -F option.
$ git config --global core.editor
C:/Program Files/Git/usr/bin/vim.exe
I've upgraded git for windows to the latest, but that didn't help. The error doesn't make any sense; vim runs fine. It says that git is waiting for vim to close "C:/Program", but that sounds like git passed vim a full path but forgot to escape the space. How could that happen?
You need to fix quotes in your .gitconfig:
git config --global core.editor "'C:/Program Files/Git/usr/bin/vim.exe'"
I have a executable file called post_deploy that's run on my OpenShift gear after a push, but it wasn't executable so I ran:
git update-index --chmod=+x .openshift/action_hooks/post_deploy
But every time I did a git add to commit the file, the file would loose the executable permission. If I tried to do a commit, git would tell me there was nothing to commit. I eventually had to pop over to Cygwin to get it to work, but how can I get this to work in Window's Command Prompt?
Check your Git version: with Git 2.9.1, you can add with chmod
git add --chmod=+x -- yourFile
Also check the value of git config core.filemode. I suspect it should be false (which is expected in an environment which does not support executable bit).
Still, the add --chmod=+x should be enough to record that executable bit in the Git repo.
Finally, clone your repo in a Linux/Cygwin environment and check if the file is not already executable there.
The OP NicholasJohn16 reports below using "How do I remove files saying “old mode 100755 new mode 100644” from unstaged changes in Git?" to solve the issue.
I've tried setting up p4merge as my mergetool, but I can't seem to get it working. Here's my commands:
git config --global merge.tool p4merge
git config --global mergetool.p4merge.path "C:/Program Files/Perforce/p4merge.exe"
git config --global mergetool.p4merge.cmd "p4merge.exe \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\""
And here's the error I'm getting:
I've also tried installing a portable version of git and running the commands from a windows cmd prompt and I still get a similar error.
Any ideas here? I'm stumped.
Edit
Strangely enough, after I've set up p4merge via git bash and it failed, I tried merging in Visual Studio's Team Explorer and it launched p4merge (tableflip). I imagine the command that kicks off via VS is similar to git bash, but I'm not sure how to correlate the two.
Edit 2:
Here's my git status showing my merge conflict status:
First, try those same config command form a regular cmd session (as I mentioned in "escape double quotes in git config from cmd").
Just make sure you have unzipped the latest git-for-windows
(PortableGit-2.8.3-64-bit.7z.exe) in, for instance, C:\git, and added C:\git\bin to your %PATH%.
Second make sure you have files that need merging, ie. that have unresolved merge conflicts (with merge conflict markers in them), in order for git mergetool to work.
When I try to commit something, not using "-m", I get this message immedately.
I changed my default editor to atom with "-w" set, also tried "-W".
git config --global core.editor -w
Using vim, it works just fine...
I'm running OSX Yosemite.
So, how can I get this to work?
Edit: Atom opens properly, but the error message gets posted before it does.
The Atom Editor Git Integration page, in the "Commit Editor" section states that you must pass the --wait flag as part of the editor command:
git config --global core.editor "atom --wait"
I am running ubuntu 12 VM using virtual box on my mac. I have cloned a git repo in a shared folder on my mac. From that folder, in my ubuntu VM, i am creating a intellij project. Trouble is, when i create that project it marks all the files as changed with no change in contents(possibly due to different line ending). How can this be avoided? I have this configuration in .gitconfig on my mac and ubuntu vm autocrlf = input.
Can someone suggest the solution?
Check that you are using git on host machine and then try to set core.autocrlf to false:
git config --global core.autocrlf false
Reset all 'changes' to head with:
git reset --hard HEAD
Also check that your git has disabled handling for filemode changes
git config --list
Should be
core.filemode=false
If not, then set it with:
git config --global core.filemode false
The easiest was is to desactive that setting:
git config --auto auto.crlf false
(on your mac)
If your IDE (here IntelliJ) doesn't change the line endings, there is no need to impose a global settings changing all the files.
If some files have to keep a specific line ending, use core.eol directive in a .gitattributes file (which isn't a local config, but a file part of your repo, and as such, pushed and pulled as the other files).
See "How line ending conversions work with git core.autocrlf between different operating systems".