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`.
Show 26 quoted lines
> 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@peff.net> 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