"Submodule registered for path" output with config aliases mixed in

>
> Hi,
>
> $ git version
> git version 2.20.1.windows.1
>
> I'm running `git clone --recurse-submodules https://...`
> The command seems to run well and completes with success.
>
> However, I noticed strange output from git:
>
> ```
> Submodule 'Binary/A' (https://...) registered for path '!f() { ~/AppData/Local/Fork/Fork.exe $PWD; }; fBinary/A'
> Submodule 'Binary/B' (https://...) registered for path 'À   ♂♦Binary/Intergraph'
> Submodule 'Binary/C' (https://....) registered for path '!sh -c 'git log $1@{1}..$1@{0} $@'Binary/C'
> Submodule 'Binary/D' (https://...) registered for path 'ls-files -o -i --exclude-standardBinary/D'
> Submodule 'Binary/E' (https://...) registered for path 'mergetool.TortoiseGitMerge.trustexitcodeBinary/E'
> ```
>
> I managed to identify where that garbage injections come from:
> from git aliases I've got configured [1]
>
> Could anyone explain what is happening here?
> Is there anything wrong with my ~/.gitconfig [1] ?
>
>
> [1] https://github.com/mloskot/wsl-config/tree/master/git
>
> --
> Best regards,
> Mateusz Łoskot, http://mateusz.loskot.net

> Hi,
> 
> $ git version
> git version 2.20.1.windows.1
> 
> I'm running `git clone --recurse-submodules https://XXX`
> The command seems to run well and completes with success.
> 
> However, I noticed strange output from git:
> 
> ```
> Submodule 'Binary/A' (https://XXX) registered for path '!f() {
> ~/AppData/Local/Fork/Fork.exe $PWD; }; fBinary/A'
> Submodule 'Binary/B' (https://XXX) registered for path 'À   ♂♦Binary/Intergraph'
> Submodule 'Binary/C' (https://XXX) registered for path '!sh -c 'git
> log $1@{1}..$1@{0} $@'Binary/C'
> Submodule 'Binary/D' (https://XXX) registered for path 'ls-files -o -i
> --exclude-standardBinary/D'
> Submodule 'Binary/E' (https://XXX) registered for path
> 'mergetool.TortoiseGitMerge.trustexitcodeBinary/E'
> ```
> 
> I managed to identify where that garbage injections come from:
> from git aliases I've got configured [1]
> 
> Could anyone explain what is happening here?
> Is there anything wrong with my ~/.gitconfig [1] ?

>
> On Tue, Feb 19, 2019 at 05:51:05PM +0100, Mateusz Loskot wrote:
> > Hi,
> >
> > $ git version
> > git version 2.20.1.windows.1
> >
> > I'm running `git clone --recurse-submodules https://XXX`
> > The command seems to run well and completes with success.
> >
> > However, I noticed strange output from git:
> >
> > ```
> > Submodule 'Binary/A' (https://XXX) registered for path '!f() {
> > ~/AppData/Local/Fork/Fork.exe $PWD; }; fBinary/A'
> > Submodule 'Binary/B' (https://XXX) registered for path 'À   ♂♦Binary/Intergraph'
> > Submodule 'Binary/C' (https://XXX) registered for path '!sh -c 'git
> > log $1@{1}..$1@{0} $@'Binary/C'
> > Submodule 'Binary/D' (https://XXX) registered for path 'ls-files -o -i
> > --exclude-standardBinary/D'
> > Submodule 'Binary/E' (https://XXX) registered for path
> > 'mergetool.TortoiseGitMerge.trustexitcodeBinary/E'
> > ```
> >
> > I managed to identify where that garbage injections come from:
> > from git aliases I've got configured [1]
> >
> > Could anyone explain what is happening here?
> > Is there anything wrong with my ~/.gitconfig [1] ?
>
> I see the right behavior on my system (Debian amd64/sid) with
> 2.21.0.rc0.258.g878e2cd30e and with master. I've built with ASan and
> don't see any memory warnings on my system.

> > > I managed to identify where that garbage injections come from:
> > > from git aliases I've got configured [1]
> > >
> > > Could anyone explain what is happening here?
> > > Is there anything wrong with my ~/.gitconfig [1] ?
> >
> > I see the right behavior on my system (Debian amd64/sid) with
> > 2.21.0.rc0.258.g878e2cd30e and with master. I've built with ASan and
> > don't see any memory warnings on my system.
> 
> I ran valgrind yesterday (gentoo amd64) and didn't find the problem
> either even though it clearly looked like some dangling pointers. I
> also audited this code and couldn't find anything obviously wrong. My
> only suspicion is maybe some strange getenv() behavior on Windows
> (_if_ the super prefix is used, but I can't see how...) and that's
> just a dead end for me.

> On Thu, Feb 21, 2019 at 10:47:45AM +0700, Duy Nguyen wrote:
>
> > > > I managed to identify where that garbage injections come from:
> > > > from git aliases I've got configured [1]
> > > >
> > > > Could anyone explain what is happening here?
> > > > Is there anything wrong with my ~/.gitconfig [1] ?
> > >
> > > I see the right behavior on my system (Debian amd64/sid) with
> > > 2.21.0.rc0.258.g878e2cd30e and with master. I've built with ASan and
> > > don't see any memory warnings on my system.
> >
> > I ran valgrind yesterday (gentoo amd64) and didn't find the problem
> > either even though it clearly looked like some dangling pointers. I
> > also audited this code and couldn't find anything obviously wrong. My
> > only suspicion is maybe some strange getenv() behavior on Windows
> > (_if_ the super prefix is used, but I can't see how...) and that's
> > just a dead end for me.
>
> Certainly we fixed a bunch of getenv() problems in the upcoming 2.21
> release, including 8aac69038f (get_super_prefix(): copy getenv() result,
> 2019-01-11).
>
> Mateusz, can you try with the one of the v2.21.0 release candidates (or
> the current tip of "master")?

> On Thu, 21 Feb 2019 at 05:17, Jeff King <peff@peff.net> wrote:
> > On Thu, Feb 21, 2019 at 10:47:45AM +0700, Duy Nguyen wrote:
> >
> > > > > I managed to identify where that garbage injections come from:
> > > > > from git aliases I've got configured [1]
> > > > >
> > > > > Could anyone explain what is happening here?
> > > > > Is there anything wrong with my ~/.gitconfig [1] ?
> > > >
> > > > I see the right behavior on my system (Debian amd64/sid) with
> > > > 2.21.0.rc0.258.g878e2cd30e and with master. I've built with ASan and
> > > > don't see any memory warnings on my system.
> > >
> > > I ran valgrind yesterday (gentoo amd64) and didn't find the problem
> > > either even though it clearly looked like some dangling pointers. I
> > > also audited this code and couldn't find anything obviously wrong. My
> > > only suspicion is maybe some strange getenv() behavior on Windows
> > > (_if_ the super prefix is used, but I can't see how...) and that's
> > > just a dead end for me.
> >
> > Certainly we fixed a bunch of getenv() problems in the upcoming 2.21
> > release, including 8aac69038f (get_super_prefix(): copy getenv() result,
> > 2019-01-11).
> >
> > Mateusz, can you try with the one of the v2.21.0 release candidates (or
> > the current tip of "master")?
> 
> Jeff, I have just tried git version 2.21.0.rc2.windows.1 and
> I no longer see the problem.
> It seems like a bug in earlier version indeed, that has been fixed now.

> Junio, Johannes: I don't know if there were particular plans to pick up
> those getenv() fixes for "maint", but if we're going to do a v2.20.2, it
> might be worth it.  It's also possible that it's just due to ca1b411648
> (mingw: safe-guard a bit more against getenv() problems, 2019-02-15),
> but I'd consider that to be maint-worthy as well.
>
> It may be that we just don't do a v2.20.2, though, since v2.21 is so
> close to release.