t/test-lib.sh: is modified when starting Visual Studio, with the open folder git mechanism

[PhilipOakley]

This maybe an 'It is what it is' situation, and just needs some notes in the wiki.

• [ x] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.34.0.rc1.windows.1
cpu: x86_64
built from commit: 3eff1fd46c1c30079d7571f94664197865a5c138
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19043.1288]

• What options did you set as part of the installation? Or did you choose the
  defaults?
  Defaults, except for editor Notepad++

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I'm using both the regular Git for Windows make and make install method for building my local git patches, and also browsing the git code using Visual Studio, via the open folder route (implies using CMake).

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (hashliteral_t)
$ git status
On branch hashliteral_t
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (hashliteral_t)
$ # start Visual Studio, opening the `git` folder                 <<<<<<<<<<<<<

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (hashliteral_t)
$ git status
On branch hashliteral_t
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   t/test-lib.sh

no changes added to commit (use "git add" and/or "git commit -a")

• What did you expect to occur after running these commands?

I was not expecting the t/test-lib.sh to be modified.

I'd seen the change in previous days, but was just browsing the code rather than patching, building and testing, so at that time it was just a mild ('unknown') annoyance.

• What actually happened instead?

t/test-lib.sh was modified.

This prevents the normal testing of the patched git because the t/test-lib.sh, implicit in the test scripts, can't find the installed git.exe.

(shifting to the sdk bash)

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (hashliteral_t)
$ git status
On branch hashliteral_t
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   t/test-lib.sh

no changes added to commit (use "git add" and/or "git commit -a")

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git (hashliteral_t)
$ cd t

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git/t (hashliteral_t)
$ ./t1007-hash-object.sh -v -i -l -x
./test-lib.sh: line 92: /c/git-sdk-64/usr/src/git/t/../contrib/buildsystems/out/build/x64-Debug/git.exe: No such file or directory
error: you do not seem to have built git yet.

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git/t (hashliteral_t)
$

But I had built git.exe ;-)

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

n/a

• Recovery Actions

check the changes

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git/t (hashliteral_t)
$ git diff
warning: CRLF will be replaced by LF in t/test-lib.sh.
The file will have its original line endings in your working directory
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2dbb526694..1ecbd0c222 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -43,7 +43,7 @@ then
        # elsewhere
        TEST_OUTPUT_DIRECTORY=$TEST_DIRECTORY
 fi
-GIT_BUILD_DIR="$TEST_DIRECTORY"/..
+GIT_BUILD_DIR="$TEST_DIRECTORY/../contrib/buildsystems/out/build/x64-Debug"

 # If we were built with ASAN, it may complain about leaks
 # of program-lifetime variables. Disable it by default to lower

phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/git/t (hashliteral_t)

This change appears to be from
C:\git-sdk-64\usr\src\git\contrib\buildsystems\out\build\x64-Debug\CTestCustom.cmake
from commits:
7f5397a
c4b2f41
.. which is not an area I'm familiar with (CTest?).

Return the file to expected state (relative to plain vanilla SDK make usage:

git checkout -- t/test-lib.sh

.. from the top level directory (cd -, possibly).

Test now runs successfully!

Should there be other ways of directing when this change happens, or is restored?

Maybe the option of a --Ctest, or --VSbuild of the test script options that would allow the shift to the alternate 'install directory we've used for Visual Studio CMake, or something like that. It may have too many catch 22 gotchas to be worth changing, and simply document the issue and reasons...

[dscho]

It is by design. From the commit message of the commit 7f5397a you yourself linked:

NOTE: t/test-lib.sh is only modified when tests are run not during the build or configure.

[PhilipOakley]

On 05/11/2021 14:47, Johannes Schindelin wrote: It is by design. From the commit message of the commit 7f5397a <7f5397a> you yourself linked: NOTE: t/test-lib.sh is only modified when tests are run not during the build or configure.

However, I didn't run any tests at the point the t/test-lib.sh was modified. From my perspective, I had only loaded git into Visual Studio, which includes the build, but doesn't run any tests. So where is the 'only when tests' design step from opening the project on VS - its seems to contradict the 'NOTE'?

…

-- Philip

[dscho]

However, I didn't run any tests at the point the t/test-lib.sh was modified.

Yes, I think that this comment might have been stale, as it is the CMake configuration that modifies the file.

In any case, your complaint is that that file is modified to begin with, and I wish there was a better way. But nobody involved in the review process could think of any other way to do this. After all, it is kind of a Catch-22 for t/test-lib.sh to find the GIT_BUILD_DIR that is no longer where it thinks it is, when the proper way would be somehow to specify that in a file in GIT_BUILD_DIR itself.

[PhilipOakley]

Thanks for the clarification. I'd written a reply earlier but I accidentality closed the tab before sending, without noticing.

I was having a think about ideas for having an ALT_BUILD_DIR setting. It is along the lines of a file containing the suffix to the current GIT_BUILD_DIR. The file being in the .gitignore list. The GIT-BUILD-OPTIONS would still indicate that a build was available in the BUILD__DIRs. If both were present then the user would need to set an env GIT_USE_ALT_BUILD flag true, otherwise the current GIT_BUILD_DIR would be used (it's logically equivalent is to check the flag first). It could work, but it's not important.. I just wanted to at least write out the idea.

[dscho]

I think you're on to something, you just need to chisel away all the unnecessary complexity.

If we introduced an optional file, living in t/, being ignored via t/.gitignore, with its contents -- if it exists -- being read and used to define that variable in t/test-lib.sh, we would have a winner. Our CMake configurations would then only need to write the absolute path of the build directory to said file instead of modifying t/test-lib.sh.