toxalot toxalot - 1 month ago 7
Git Question

How do I get COMMIT_EDITMSG to open from the correct location?

I'm new to GIT. I downloaded GIT for Windows from a GitHub link a few days ago. I'm using the command line tool MinGW32. I'm not comfortable with the default editor so I've been trying to set up my favourite editor.

I followed the instructions here to use
EditPad Pro as my editor. But I keep getting the following message:

Aborting commit due to empty commit message.


EditPad Pro opens a new instance. MinGW32 is waiting because I don't get the abort message until after I close EditPad Pro. When the editor opens, it opens with a blank file called
COMMIT_EDITMSG
. When I close the editor, the file saves to the main directory for the repo.

I found a clue in this answer, specifically this phrase:


[Vim] saves the file to .git/COMMIT_EDITMSG by default


If I do a Save As to save the file to the .git directory before closing the editor, then it works. However, there are two problems with that:


  1. I have to remember to Save As

  2. I don't get the helpful comments that Git adds by default to COMMIT_EDITMSG



The current config setting for
core.editor
is:

"'D:\Program Files\JGsoft\EditPadPro5\EditPad Pro.exe' //newinstance"


I'm not sure what the
$*
mentioned in the instructions is for, but I tried it with and without that and also assorted variations with and without single/double quotes. I tried setting the value in a shell script as well. At worst, it doesn't work at all (e.g. won't even open the editor) and at best it opens a blank file.

How do I get my editor to open with the file that Git created in the .git directory?

EDIT: I get the exact same results whether I use
$*
or not, and this answer says it's not needed. This Git Pro page makes mention of it when explaining how to set up external merge and diff tools, but makes no mention of it when explaining the
core.editor
config setting. Note: I also tried
%*
.

If the
$*
variable was needed (and missing), I would think that EditPad Pro would open with a blank Untitled file rather than a blank COMMIT_EDITMSG file in the current directory. The problem seems to be the path.

EDIT: I've done more experimenting. I have spaces in my file path and I thought that might be causing a problem. I cloned my repo into a new directory with no spaces in the name and fixed my config variables. It didn't solve the problem. But I noticed another problem. In some of my tests, the blank file that was loaded into the editor was named
$@
.

Answer

There are several issues that can be causing confusion and problems.

  1. The Shell Special Variable

    If core.editor is set to the editor path and filename, then the $* variable is redundant and not needed. However, if the core.editor is set to a shell script, then the $* variable must be passed along to the editor.

    This is valid:

    $ git config --global core.editor "'D:/Path To/EditPadPro.exe' //newinstance"
    

    This is also valid:

    $ git config --global core.editor "'E:/Path To/editor.sh'"
    

    when editor.sh contains:

    #!/bin/sh
    "D:/Path To/EditPadPro.exe" //newinstance "$*"
    
  2. Spaces in File Names

    Filenames with spaces can be a pain. If the path/filename is quoted, then it isn't usually a problem. But when setting the value of core.editor you have to either

    escape the spaces like this:

    "E:/Path\ To/editor.sh"
    

    or quote it twice like this:

    "'E:/Path To/editor.sh'"
    

    Without the extra quotes (or backslash escapes), you will have no problem setting the value, but it will fail when it's used because the outer quotes are not part of the value.

    EDIT: Latter method (quoting twice) seems safer. See the edit at the bottom for more explanation.

  3. Windows Path Separator

    The filename that is being passed to the editor can be a relative path (i.e. .git/COMMIT_EDITMSG) or absolute path (i.e. e:/path to/.git/rebase-merge/git-rebase-todo), but in both cases it is using forward slashes as a path separator. Windows can usually accept forward slashes as a path separator, especially if the path is quoted. Perhaps the older version of EditPad Pro is unable to accept the forward slashes in combination with the hidden directory. A little bit of preprocessing can fix this.

    Note: Hardcoded paths with forward slashes and no hidden directory seem to work fine. Hardcoded paths with hidden directories and backslashes seem to work fine.

Final Solution

I'm not very experienced with shell scripting, but the following is now working for me.

The editor.sh file contains:

#!/bin/sh
fullpath=`echo "$*" | tr '/' '\\\'`
"D:/Program Files/JGsoft/EditPadPro5/EditPadPro.exe" //newinstance "$fullpath"

and the config is set like this:

$ git config --global core.editor "'E:/Path To/editor.sh'"

My copy of EditPad Pro 5.3.2 is now opening with the correct files already loaded, regardless of what git command launches the editor.

EDIT: I had to change the value of core.editor. I had used backslashes to escape spaces in the path and this opened the editor properly. However, when a GIt command passed a fielname with a relative path (beginning with a dot) to my shell script, the value of $* was $@ rather than the filename, which caused the editor to open with a blank file named $@. I thought I tested that combination, but apparently not. Using the quote twice method works.