(0027328)
Brad King (manager)
2011-09-05 07:56

What are these problems? I've never had a problem running git.cmd for anything. I've heard some people complain about this but I've never been able to reproduce it.

What version of msysGit shows the problem?

What errors are produced?

Can the problem be duplicated in a small project?

(0027346)
David Cole (manager)
2011-09-05 11:58

The reason we prefer "git.cmd" over git.exe is because it sets up the proper HOME environment variable necessary for git ssh connections to work the same as they do from the git bash prompt.

There should be no reason that it works any differently than git.exe. If there's a problem with executing multiple calls to git.cmd, then we should figure what the problem is there and fix that, not simply replace git.cmd with git.exe.

On a project-by-project basis, of course, you're free to do whatever you want, but I think git.cmd is still the one to prefer by default...

(0027347)
David Cole (manager)
2011-09-05 11:59

As Brad, says "what are these problems?"

Please give steps to reproduce so that we may address the problems you're having with using "git.cmd" rather than simply avoiding the problem...

(0027349)
Sascha Zelzer (reporter)
2011-09-05 12:08

I have been reading up on what git.cmd is supposed to do and I totally agree with your comments. Since we are not doing ssh git clones, the workaround of using git.exe instead works for now for our project.

I will cook up an example project demonstrating the problem this week.

(0027350)
David Cole (manager)
2011-09-05 12:15

You don't even need a whole separate FindGit.cmake module to make this work in your project. The only thing FindGit really does right now is set GIT_EXECUTABLE to the full path to the git program.

You could use the following code, prefer git.exe over git.cmd, and still use the built-in FindGit.cmake:

if(EXISTS "C:/Program Files (x86)/Git/bin/git.exe")
set(GIT_EXECUTABLE "C:/Program Files (x86)/Git/bin/git.exe" CACHE FILEPATH "prefer git.exe")
elseif(EXISTS "C:/Program Files/Git/bin/git.exe")
set(GIT_EXECUTABLE "C:/Program Files/Git/bin/git.exe" CACHE FILEPATH "prefer git.exe")
endif()
find_package(Git)

(0027374)
Sascha Zelzer (reporter)
2011-09-06 09:14

Hi,

the attached CMakeLists.txt file demonstrates the problem with git.cmd under Windows (tested with CMake 2.8.5).

If you build the ALL_BUILD project in Visual Studio, the git repository created in the build directory will always be dirty. This does not happen if you use git.exe .

Note that the multiple "COMMAND" arguments form in add_custom_target is also used in the ExternalProject.cmake script to update projects which use a tracking branch as GIT_TAG and hence the update fails (silently) on Windows with git.cmd because only the fist COMMAND (fetch) is executed, but not the actual checkout.

(0027375)
Brad King (manager)
2011-09-06 09:45

I think this fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d093abef [^]

is needed for the VS generators too. When git.cmd is invoked from the batch script generated for the custom command, it exists the whole batch script because it was not invoked with "call ...".

(0027376)
Brad King (manager)
2011-09-06 09:51

The fix will be somewhere around here:

http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudioGenerator.cxx;hb=v2.8.5#l252 [^]

(0027818)
David Cole (manager)
2011-11-18 10:31

Fix pushed to 'next':

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46c70540ede37c5f2ebeeeba4178340abf92fadb [^]

(0029045)
David Cole (manager)
2012-04-02 10:10

Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2011-09-03 09:53	Jean-Christophe Fillion-Robin	New Issue
2011-09-05 07:56	Brad King	Note Added: 0027328
2011-09-05 11:58	David Cole	Assigned To	=> David Cole
2011-09-05 11:58	David Cole	Status	new => assigned
2011-09-05 11:58	David Cole	Note Added: 0027346
2011-09-05 11:59	David Cole	Note Added: 0027347
2011-09-05 12:08	Sascha Zelzer	Note Added: 0027349
2011-09-05 12:15	David Cole	Note Added: 0027350
2011-09-06 09:10	Sascha Zelzer	File Added: CMakeLists.txt
2011-09-06 09:14	Sascha Zelzer	Note Added: 0027374
2011-09-06 09:45	Brad King	Note Added: 0027375
2011-09-06 09:51	Brad King	Note Added: 0027376
2011-09-19 10:01	Brad King	Relationship added	related to 0012461
2011-10-25 21:52	David Cole	Target Version	=> CMake 2.8.7
2011-11-18 10:31	David Cole	Note Added: 0027818
2011-11-18 10:31	David Cole	Status	assigned => resolved
2011-11-18 10:31	David Cole	Fixed in Version	=> CMake 2.8.7
2011-11-18 10:31	David Cole	Resolution	open => fixed
2012-04-02 10:10	David Cole	Note Added: 0029045
2012-04-02 10:10	David Cole	Status	resolved => closed
2013-06-04 16:20	Brad King	Relationship added	has duplicate 0014203

Notes
(0027328) Brad King (manager) 2011-09-05 07:56	What are these problems? I've never had a problem running git.cmd for anything. I've heard some people complain about this but I've never been able to reproduce it. What version of msysGit shows the problem? What errors are produced? Can the problem be duplicated in a small project?

(0027346) David Cole (manager) 2011-09-05 11:58	The reason we prefer "git.cmd" over git.exe is because it sets up the proper HOME environment variable necessary for git ssh connections to work the same as they do from the git bash prompt. There should be no reason that it works any differently than git.exe. If there's a problem with executing multiple calls to git.cmd, then we should figure what the problem is there and fix that, not simply replace git.cmd with git.exe. On a project-by-project basis, of course, you're free to do whatever you want, but I think git.cmd is still the one to prefer by default...

(0027347) David Cole (manager) 2011-09-05 11:59	As Brad, says "what are these problems?" Please give steps to reproduce so that we may address the problems you're having with using "git.cmd" rather than simply avoiding the problem...

(0027349) Sascha Zelzer (reporter) 2011-09-05 12:08	I have been reading up on what git.cmd is supposed to do and I totally agree with your comments. Since we are not doing ssh git clones, the workaround of using git.exe instead works for now for our project. I will cook up an example project demonstrating the problem this week.

(0027350) David Cole (manager) 2011-09-05 12:15	You don't even need a whole separate FindGit.cmake module to make this work in your project. The only thing FindGit really does right now is set GIT_EXECUTABLE to the full path to the git program. You could use the following code, prefer git.exe over git.cmd, and still use the built-in FindGit.cmake: if(EXISTS "C:/Program Files (x86)/Git/bin/git.exe") set(GIT_EXECUTABLE "C:/Program Files (x86)/Git/bin/git.exe" CACHE FILEPATH "prefer git.exe") elseif(EXISTS "C:/Program Files/Git/bin/git.exe") set(GIT_EXECUTABLE "C:/Program Files/Git/bin/git.exe" CACHE FILEPATH "prefer git.exe") endif() find_package(Git)

(0027374) Sascha Zelzer (reporter) 2011-09-06 09:14	Hi, the attached CMakeLists.txt file demonstrates the problem with git.cmd under Windows (tested with CMake 2.8.5). If you build the ALL_BUILD project in Visual Studio, the git repository created in the build directory will always be dirty. This does not happen if you use git.exe . Note that the multiple "COMMAND" arguments form in add_custom_target is also used in the ExternalProject.cmake script to update projects which use a tracking branch as GIT_TAG and hence the update fails (silently) on Windows with git.cmd because only the fist COMMAND (fetch) is executed, but not the actual checkout.

(0027375) Brad King (manager) 2011-09-06 09:45	I think this fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d093abef [^] is needed for the VS generators too. When git.cmd is invoked from the batch script generated for the custom command, it exists the whole batch script because it was not invoked with "call ...".

(0027376) Brad King (manager) 2011-09-06 09:51	The fix will be somewhere around here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudioGenerator.cxx;hb=v2.8.5#l252 [^]

(0027818) David Cole (manager) 2011-11-18 10:31	Fix pushed to 'next': http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46c70540ede37c5f2ebeeeba4178340abf92fadb [^]

(0029045) David Cole (manager) 2012-04-02 10:10	Closing resolved issues that have not been updated in more than 4 months.