[Basic] Revise version printing

[davezarzycki]

Now that we use the LLVM mono-repo, we don't need to worry about clang's version number. Also, git has the ability to estimate the safe number of digits a hash can be truncated to and now git estimates that large projects like LLVM and Linux "require" 12 digits for safe commit hash abbreviation. Let's stay a little ahead of the curve and statically truncate to 15.

[davezarzycki]

@swift-ci please smoke test

[davezarzycki]

An aside / digression: I'd not bother truncation the git hashes. Yes, truncation is useful when using git with --oneline output but that isn't this scenario.

1. People are just going to double-click, copy, and paste so length doesn't matter.
2. Only devs and testers should see the hashes and they can deal with line wrap.

[compnerd]

Hmm, like a reasonable thing, but I would prefer that if we do this, we update the build to avoid the clang version definition in the generated file.

Any reason to not just use the full abbreviated hash from git?

[davezarzycki]

What do you mean by "full abbreviated hash"? That sounds like a contradiction :-)

[davezarzycki]

No longer generating/including ClangRevision.inc.

I'd still like people to consider not truncating the git hashes, but I don't feel strongly about this.

@swift-ci please smoke test

[compnerd]

What do you mean by "full abbreviated hash"? That sounds like a contradiction :-)

Haha, fair point. What I meant is that rather than truncating in the code to some limit why not print the exact result of git log -1 --pretty=%h. Let git decide what the number of characters should be - if thats 12 then its 12. We don't know whats going on with the SCM and we shouldn't really care either.

I agree with your point that we shouldn't bother truncating to some "safe" amount. But we can have the best of the both worlds as git knows how to print the short form too.

[davezarzycki]

I think this is one of those scenarios where it's easy to over-think a problem. I'd vote for just doing the full hash, and see when/if people complain. If people do, then we can address the complaints rather than speculate.

[compnerd]

That also seems fine by me. I’m also okay with you doing that in a follow up change if you would like.

[davezarzycki]

I think we should get someone at Apple to review this given the output of the REPL on my macOS box

[compnerd]

CC: @JDevlieghere @adrian-prantl

[davezarzycki]

@swift-ci please test