git --version should output 32 or 64-bit.

[cchan]

• I was not able to find an open
  or closed issue
  matching what I'm seeing
  (although since almost every issue has "git version" in its content that's not very helpful)

Instead of

$ git --version
git version 2.9.2.windows.1

why not

$ git --version
git version 2.9.2.windows-x86.1

and

$ git --version
git version 2.9.2.windows-x64.1

I'd pull request, but I can't find any reference to it in the code, so I'm guessing it's bundled in when it's compiled. No idea though.

[landstander668]

This sounds like a useful enhancement, although I'm not sure if it's a good idea to add that to the main output string since tools/scripts could well be relying on the current format. Adding a line to the --build-options output seems like it should be relatively safe, however. Something like:

$ git version --build-options
git version 2.9.2.windows.1
sizeof-long: 4
platform: x64

@dscho, do you have an opinion/preference on which way this should go? I'm willing to create a pull request and run with it.

[dscho]

@landstander668 A PR would be lovely! I have a strong preference to --build-options because the architecture is not really a part of the version. I would call it machine: x86_64, though, as it reflects the output of uname --machine ;-)

[PhilipOakley]

I think it would be worthwhile, in the version string, as long as the 32/64 bit indication is near the end. Remember that when a dev has added his new patches, compiled (and tested) his updated version the string will also have appended the -g suffix, so a variable (changing) version string is nothing unusual

[cchan]

Hmm, good point @dscho - the architecture can be different but the underlying code is the same, so the version should be the same.

[landstander668]

It'll probably be a few days due to work constraints, but I'll get to work on this shortly. Unless someone beats me to it, of course. (-;

[dscho]

when a dev has added his new patches

I would like to remind everyone that developers are not necessarily male. The first software developers were all female, as a matter of fact. This is something I care about deeply, so please refrain from using the male pronoun to refer to software developers.

I think it would be worthwhile, in the version string, as long as the 32/64 bit indication is near the end.

I would really rather have this feature as a --build-options one. The idea is to describe the version of the source code, after all. We try to infer more information from that version string, of course, such as mapping it to the package versions whose files were included in the Git for Windows installer that bundled the Git executable reporting this version. But technically that is incorrect, as those package versions have nothing to do with the version of the source code from which the Git executable was built.

In addition, I would really like to caution that certain tools (most prominently, IDEs such as Visual Studio) rely on a certain format. We should not break those expectations on a whim.

[cchan]

@dscho You mentioned the install-options.txt file in #847; should we also add Platform:/Architecture:/Machine: to this file?

Currently all it contains (for me) is:

Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled

It's not an "install option" that was chosen during installation, but it was an option chosen by the user when they downloaded the installer, and it seems relevant in any case.

[landstander668]

Sorry for the delay, but work has finally calmed down enough for me to followup on this issue. I've just submitted Pull Request #866, which contains a (very preliminary) patch adding build platform to the git version --build-options output.

I may be adequate for the needs of Git for Windows at this point (although the output might need some tweaking), but requires additional work before it will be ready for inclusion upstream.

[dscho]

Thanks @landstander668 for your excellent contribution! It is now live, in v2.10.0.