error: committer identity unknown; please configure `user.name` and `user.email`

[char101]

Hi,

I tested running stg init (OS: Windows 10) and although I have user.name and user.email configured, I got this message: error: committer identity unknown; please configure user.name and user.email.

R:\test-git>git config --show-origin -l | rg user
file:A:/Home/.gitconfig user.name=Charles
file:A:/Home/.gitconfig user.email=my@email

R:\test-git>echo %HOME%
A:\Home

R:\test-git>stg init
error: committer identity unknown; please configure `user.name` and `user.email`.

Looking at the source it should have found the config file at HOME.

https://docs.rs/gix-config/0.34.0/src/gix_config/source.rs.html#103

For it to work I have to make a symlink from USERPROFILE to HOME, which is not a big deal but the behavior does not conform to git behavior

R:\test-git>mklink %USERPROFILE%\.gitconfig %HOME%\.gitconfig
symbolic link created for C:\Users\char\.gitconfig <<===>> A:\Home\.gitconfig

R:\test-git>stg init

[jpgrayson]

Thanks for this issue report @char101.

gitoxide uses the home crate, which has very specific policy regarding how the HOME environment variable is (or isn't) used on Windows.

I think the docs for home::home_dir() may be relevant for this issue. Specifically, it looks like the USERPROFILE environment variable is going to be used to find the user's "home" on Windows, followed by some Windows API calls if USERPROFILE isn't set.

So I wonder how your %USERPROFILE% compares to your %HOME%? And whether placing your global .giticonfig in %USERPROFILE% might resolve the StGit problem? And if so, does git still find your global config if it's in %USERPROFILE%?

I do not have a Windows environment on-hand, so I could use help with this additional triage. Thanks!

[char101]

I think the docs for home::home_dir() may be relevant for this issue. Specifically, it looks like the USERPROFILE environment variable is going to be used to find the user's "home" on Windows, followed by some Windows API calls if USERPROFILE isn't set.

Changing HOME environment variale is usually safe because it is usually only used by linux apps that is ported to Windows. Changing USERPROFILE environment variable is a bit more dangerous because because it is also used by Windows itself. Also it is hit and miss, HOME is more commonly supported and also cross-platform.

So I wonder how your %USERPROFILE% compares to your %HOME%

I generally don't like storing config files in USERPROFFILE because it is a mess.

And whether placing your global .giticonfig in %USERPROFILE% might resolve the StGit problem

It did. I can run stgit by symlinking %HOME%\.gitconfig to '%USERPROFILE%.gitconfig`

The problem is that the HOME environment variable is perfectly supported by git on Windows, so I think any application that read git config should conform to it. But of course if the cause is underlying library then there is probably nothing that stgit can do about it.

And if so, does git still find your global config if it's in %USERPROFILE%

No, actually if I symlink .gitconfig from HOME to USERPROFILE, the USERPROFILE .gitconfig does not appear in git config -l --show-origin list, probably because git already find one in HOME. And placing .gitconfig in USERPROFILE is not something I want to do.

[char101]

Another problem with stgit on Windows is that it failed to launch the configured editor:

[Thu Jan 25 06:47] R:\test-git [master]
> stg init

[Thu Jan 25 06:47] R:\test-git [master]
> stg new patch1
hint: Waiting for your editor to close the file...
error: program not found

[Thu Jan 25 06:47] R:\test-git [master]
> git config -l | rg editor
core.editor=A:/Editor/vim/launcherwait.exe

[jpgrayson]

Thank you for the additional triage, @char101. Regarding how HOME is treated, I think that both StGit and gitoxide both strive to do what git does in these kind of situations. Perhaps @Byron would be interested in this issue.

---

Regarding the editor not being launched as expected when running stg new, here is the relevant StGit code at play:

https://github.com/stacked-git/stgit/blob/master/src/patch/edit/interactive.rs#L97-L105

Which is trying to emulate how git runs an editor subprocess. Note specifically how it tries to run the command via sh. This comes from this git code:

https://github.com/git/git/blob/e02ecfcc534e2021aae29077a958dd11c3897e4c/run-command.c#L275-L300

So I don't know if the problem is with running your editor, or running sh. There is sort of an assumption that StGit will be run in a context where git-for-windows will be run such that sh would be available. Again, I'm not a Windows user and don't have an environment on-hand, so I would again need help with further triage of this editor issue.

[char101]

Thanks for the links for the editor launch code. There are some points that I can make of it

• the error: program not found is most likely caused by it not finding sh.exe, not the editor executable itself
• the shell in Windows is cmd.exe, the command line to launch is cmd.exe /c <args>
• even when installing git for Windows, there is an option to only expose git.exe on the PATH environment variable, so there is no guarantee that sh.exe is in the PATH
• I tried to launch gvim.exe using cmd.exe /c gvim.exe and it did not wait for gvim.exe to terminate. I don't think launching an editor application in Windows requires a shell.
• Using sh.exe to launch my editor did wait for it to terminate, but the application path need to use forward slashes.

[Thu Jan 25 21:09] C:\
> which git
C:\Program Files\Git\cmd\git.exe

[Thu Jan 25 21:15] C:\
> which sh
INFO: Could not find files for the given pattern(s).

[Thu Jan 25 21:16] C:\
> cmd.exe /c A:\Editor\vim\gvim.exe <- does not wait

[Thu Jan 25 21:20] C:\
> "C:\Program Files\Git\usr\bin\sh.exe" -c A:/Editor/vim/gvim.exe <- do wait, but requires forward slashes

If I add sh.exe to PATH, then the editor works

[Thu Jan 25 21:22] R:\test-git [master]
> set PATH=C:\Program Files\Git\usr\bin;%PATH%

[Thu Jan 25 21:22] R:\test-git [master]
> stg new patch-1
hint: Waiting for your editor to close the file... <- works, the gvim editor is displayed
> patch-1 (new)

[char101]

From https://stackoverflow.com/questions/10564/how-can-i-set-up-an-editor-to-work-with-git-on-windows

using cmd.exe /c start /wait <editor-path> do wait for the editor to terminate, so it might be an alternative to sh.exe

[Thu Jan 25 21:26] R:\test-git [master]
> cmd.exe /c start /wait A:\Editor\vim\gvim.exe <- wait for gvim.exe to teminate

[jpgrayson]

If I add sh.exe to PATH, then the editor works

I think this is the key. It's not just sh you're getting from C:\Program Files\Git\usr\bin, but also git itself. Although StGit does a lot with the gitoxide library, it also runs git subprocesses for a lot of things. I suspect that even if StGit didn't try to run the editor using sh, the next problem in line would have been StGit failing due to git not being in the PATH.

So from where I'm sitting, it seems like StGit using sh to wrap editor commands remains the correct approach. Note that using sh enables using shell capabilities for core.editor, such as referring to an environment variable. Using cmd.exe or executing the core.editor value directly would cause other incompatibilities with valid core.editor setups.

[char101]

git.exe is not installed in bin, but in cmd. This has been the (default?) mode for a long time. Adding all msys executables to the PATH might polute the PATH since it is a private git msys installation. In Windows, PATH is also used to load dlls unlike linux paths.

[Thu Jan 25 21:09] C:\
> which git
C:\Program Files\Git\cmd\git.exe

[Thu Jan 25 21:28] R:\test-git [master]
> dir "c:\Program Files\Git\cmd
 Volume in drive C is Win10
 Volume Serial Number is 7291-C0A8

 Directory of c:\Program Files\Git\cmd

2023/12/23  22:44    <DIR>          .
2023/12/23  22:44    <DIR>          ..
2023/11/20  18:47             1.038 aslr-manager.ps1
2023/11/20  18:35           136.200 git-gui.exe
2023/11/20  18:35            45.048 git-lfs.exe
2023/11/20  18:35            33.436 git-receive-pack.exe
2023/11/20  18:35            33.436 git-upload-pack.exe
2023/11/20  18:35            45.048 git.exe
2023/11/20  18:35           136.200 gitk.exe
2023/11/20  18:35            45.048 scalar.exe
2023/11/20  18:35             3.022 start-ssh-agent.cmd
2023/11/20  18:35             2.723 start-ssh-pageant.cmd
              10 File(s)        481.199 bytes
               2 Dir(s)  24.130.527.232 bytes free

[char101]

Git installer screenshot. The recommeded option is to only add git.exe and some other wrapper to PATH.

[char101]

As for git executables, it doesn't seem to be a problem

[Thu Jan 25 22:40] R:\test-git [master]
> stg log
427cdeb   Thu, 25 Jan 2024 22:39:32 +0700   refresh patch-1
5bbeebf   Thu, 25 Jan 2024 22:39:32 +0700   refresh refresh-temp (create temporary patch)
56db13b   Thu, 25 Jan 2024 21:22:42 +0700   new: patch-1
a005926   Thu, 25 Jan 2024 06:47:24 +0700   initialize

[Thu Jan 25 22:40] R:\test-git [master]
> which git-log
INFO: Could not find files for the given pattern(s).

[Thu Jan 25 22:40] R:\test-git [master]
> git show 427cdeb
commit 427cdebb2630946a90114b50149d00eb071af4a5
Author: Charles <peacech@gmail.com>
Date:   Thu Jan 25 22:39:32 2024 +0700

    refresh patch-1

[char101]

git.exe that is accessible from the PATH is just a wrapper that run the real git.exe. The real git.exe itself is not accessible from the PATH.

https://github.com/git-for-windows/MINGW-packages/blob/main/mingw-w64-git/git-wrapper.c