-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git for Windows Version information #5319
Comments
The reason why Git for Windows v2.47.1 is internally labeled "v2.47.1.1" or "v2.47.1.windows.1" is that there are a metric ton of patches on top of Git v2.47.1. The |
Thank You, that answers the 'actual version' question ;-) Would you therefore be able to do anything about populating the FileVersion attribute on any Git for Windows executables & DLL's with this correct version |
I am quite sure that I have more pressing things to take care of; This feature request does not strike me as meeting the bar to drop those more pressing issues in favor of changing the way the version is encoded. As far as I can tell, Git for Windows' version information is consistent enough. If you feel strongly enough, I invite you to invest your own time on this project. |
Apologies, I did not mean to offend or cause you extra stress, I was simply highlighting that the application has the version encoding into the FileVersion attribute in the incorrect format for a standard 2, 3 or 4 part Windows File Version. |
Setup
Windows 10 Enterprise Version 22H2 64-bit
defaults?
to the issue you're seeing?
N/A
Details
CMD or PowerShell
Minimal, Complete, and Verifiable example
this will help us understand the issue.
Consistent Version numbering
The 1st command returns:
As you can see (for any of the latest Git components) this is either "2.47.1.windows.1" for ProductVersion or FileVersion, but "2.47.1.1" for FileVersionRaw
Whereas the 2nd Command returns "2.47.1" from the DisplayVersion held in the registry
URL to that repository to help us with testing?
N/A
The problem with this inconsistency is it makes it very difficult to use 'standard' Windows checks to determine the version of the product that is actually installed, As an example we use Microsoft Intune to deploy software to many endpoints and one of the detection methods available to us when a product is deployed is to use a String (Version) check against a defined file (e.g.
C:\Program Files\Git\git-cmd.exe
), this checks for a standard 4 part version number held in the FileVersion attribute on the chosen file.As you can see from the above results the FileVersion on your files contains 5 parts. This unfortunately is not a normal 'Windows' defined version number (i.e. Major.Minor.Build.Revision), so this check fails (Unfortunately Intune (and many other deployment tools) does not give the option to choose an (alternative) attribute to use) so for Git for Windows the FileVersion attribute can not be used to detect the installed version.
One question I do have is what is the actual [version] number for this release? is it
2.47.1
,2.47.1.1
or something else?If it is something else (i.e.
"2.47.1.windows.1"
) I need to find a native Windows method to return the correct standard Windows version number.One solution I could recommend is for your development build process to put the standard Windows format numeric version number (e.g.
2.47.1.1
into the FileVersion Attribute on your windows compiled executables (.exe) and dynamic linked librarys (.dll) and leave the Product Version as-is, that way many products that attempt to read the version info from an executable or dll file can correctly determine it.The text was updated successfully, but these errors were encountered: