I'm confident there is an error in the `git config --global -e` pipeline though (very likely git.c), because when using git-aliases the function performs as expected. My current alias `ec` pointing to the command `!vi $HOME/.gitconfig` - where $HOME is `/root`. The full command looks like `git ec` and works as expected. Meaning that the only difference between the failed-run and successful-run was calling the git built-in `git config --global -e`. > On Apr 10, 2023, at 16:49, Hello World! <mail@mervin.works> wrote: > > Using the command, the trace says it’s using 'vi /root/.gitconfig' - which is indeed the set editor. > > For more verbosity, the call-chain is 'git.c' (trace: built-in: git config) → 'run_command.c' (trace: run_command: 'vi /root/.gitconfig') which doesn’t seem strange. >>> On Apr 10, 2023, at 16:25, Jeff King <peff@xxxxxxxx> wrote: >>> On Mon, Apr 10, 2023 at 03:44:26PM -0400, Mervin Guy wrote: >>> >>> What did you do before the bug happened? (Steps to reproduce your issue) >>> - Changed my directory to a git-repo I was working on, using 'cd <directory_name>'. Then I ran 'git config --global -e'. >>> What did you expect to happen? (Expected behavior) >>> - I exepected the command to display my current-config file, with all settings included, in my editor. >>> What happened instead? (Actual behavior) >>> - My config-file was overwritten and displayed a default-setup message, the config-file was lost after this point. >>> I experimented with different ways of activating the command, but they all led to an overwrite of the file. >> >> That's certainly unexpected. "git config --global -e" works fine for me. >> And Git itself won't overwrite the file; it will run your editor with >> the name of the file, and the editor is responsible for any writing. >> Which editor are you trying to use? Can you try running with: >> >> GIT_TRACE=1 git config --global -e >> >> which should show the editor command that Git runs. >> >> -Peff