MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012445CMakeModulespublic2011-09-03 09:532013-06-04 16:20
ReporterJean-Christophe Fillion-Robin 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionCMake 2.8.7Fixed in VersionCMake 2.8.7 
Summary0012445: Do not use git.cmd in FindGit module
DescriptionFrom Sascha Zelzer [See See https://github.com/commontk/CTK/issues/35 [^]]

CTK relies on the "official" FindGit.cmake script, which gives precedence to "git.cmd" when looking for a git executable.

On Windows, using git.cmd instead of git.exe leads to problems when used in the default git update command of the ExternalProject_Add macro. The default update command should execute several git calls (fetch, checkout, submodule update) where only the first is actually run. Using git.exe, all calls are executed correctly.

We should roll our own version of FindGit.cmake, giving priority to git.exe on Windows. This should probably also be fixed in the CMake version of the script.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0014203closed  Automatically add "call" in "add_custom_command()". 
related to 0012461closed David Cole externalproject_add with GIT : fetch without merge 
Attached Filestxt CMakeLists.txt (920) 2011-09-06 09:10
https://public.kitware.com/Bug/file/4047/CMakeLists.txt
Issue History
Date ModifiedUsernameFieldChange
2011-09-03 09:53Jean-Christophe Fillion-RobinNew Issue
2011-09-05 07:56Brad KingNote Added: 0027328
2011-09-05 11:58David ColeAssigned To => David Cole
2011-09-05 11:58David ColeStatusnew => assigned
2011-09-05 11:58David ColeNote Added: 0027346
2011-09-05 11:59David ColeNote Added: 0027347
2011-09-05 12:08Sascha ZelzerNote Added: 0027349
2011-09-05 12:15David ColeNote Added: 0027350
2011-09-06 09:10Sascha ZelzerFile Added: CMakeLists.txt
2011-09-06 09:14Sascha ZelzerNote Added: 0027374
2011-09-06 09:45Brad KingNote Added: 0027375
2011-09-06 09:51Brad KingNote Added: 0027376
2011-09-19 10:01Brad KingRelationship addedrelated to 0012461
2011-10-25 21:52David ColeTarget Version => CMake 2.8.7
2011-11-18 10:31David ColeNote Added: 0027818
2011-11-18 10:31David ColeStatusassigned => resolved
2011-11-18 10:31David ColeFixed in Version => CMake 2.8.7
2011-11-18 10:31David ColeResolutionopen => fixed
2012-04-02 10:10David ColeNote Added: 0029045
2012-04-02 10:10David ColeStatusresolved => closed
2013-06-04 16:20Brad KingRelationship addedhas duplicate 0014203

Notes
(0027328)
Brad King   
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   
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   
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   
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   
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   
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   
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   
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   
2011-11-18 10:31   
Fix pushed to 'next':

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46c70540ede37c5f2ebeeeba4178340abf92fadb [^]
(0029045)
David Cole   
2012-04-02 10:10   
Closing resolved issues that have not been updated in more than 4 months.