On Wed, May 05, 2021 at 09:06:12PM +0300, Theodor Negrescu wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> I ran the command "git config --file ~/git-settings/.gitconfig -l"
> (git-settings is a repo where I keep my config, the global one is just
> an include)
>
> What did you expect to happen? (Expected behavior)
>
> It would list the settings in the file.
>
> What happened instead? (Actual behavior)
>
> fatal: unable to read config file '~/git-settings/.gitconfig': No such
> file or directory
>
> What's different between what you expected and what actually happened?
>
> The ~ symbol should point to my home folder.
I don't think this is a bug in git-config. It is generally the shell
that is responsible for expanding "~" and passing along the result to
commands. E.g.:
$ strace -e execve git config --file ~/foo --list
execve("/home/peff/local/git/current/bin/git", ["git", "config", "--file", "/home/peff/foo", "--list"], 0x7ffc10a88130 /* 55 vars */) = 0
> [System Info]
> git version:
> git version 2.31.1.windows.1
> cpu: x86_64
> built from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 19042
> compiler info: gnuc: 10.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): <unset>
I'd guess this might be related to Windows somehow. Are you entering the
command in a bash shell, or via some other mechanism?
-Peff
