git doesn't recognize `set GIT_TRACE=1`, but does recognise `set "GIT_TRACE=1"`

[framlingham]

On Win10 x64, I was trying to set environment variables in CMD to diagnose an issue, and was running:

set GIT_TRACE=1 & git lfs fetch

warning: unknown trace value for 'GIT_TRACE': 1
         If you want to trace into a file, then please set GIT_TRACE
         to an absolute pathname (starting with /)
...

I have git version 2.42.0.windows.2, as well as TortoiseGit version 2.15.0 and git-lfs/3.4.0 (GitHub; windows amd64; go 1.20.6; git d06d6e9e).

I felt like I was falling down the rabbit hole, but somehow found out that this is different to the above:

set "GIT_TRACE=1" & git lfs fetch

It took me too long to figure out. I think maybe the first one is a string with one character, as in "1", but the second one is an integer 1. Can you please make git to accept either? If not, please update doco to mention it?

[dscho]

set GIT_TRACE=1 & git lfs fetch

Contrary to what you think you've set GIT_TRACE to, it is not 1 but 1 (note the trailing space!). This can be verified as following:

C:\Users\me>set GIT_TRACE=1 & git -c alias.sh="!sh" sh -c "env | grep GIT_TRACE | xxd -g 1"
warning: unknown trace value for 'GIT_TRACE': 1
         If you want to trace into a file, then please set GIT_TRACE
         to an absolute pathname (starting with /)
00000000: 47 49 54 5f 54 52 41 43 45 3d 31 20 0a           GIT_TRACE=1 .

Note the 20 (which is the hex code for the ASCII space) after the 31 (hex code for ASCII digit 1).

The reason for the observed behavior, therefore, is not Git, but the invocation and how CMD interprets it. Whether this constitutes a bug in CMD or its documentation is for someone else than me to decide.

You can work around it by removing the space between the 1 and the &:

set GIT_TRACE=1& git lfs fetch