v.util.version: fix output for V full version

[lcheylus]

• vhash() function returns full hash (C.V_COMMIT_HASH) ; length = 50, see v/util/version/version.c.v
• vcurrent_hash() returns short form (length = 7)

Tests OK on Linux Debian/testing

With a clean Git worktree (C.V_COMMIT_HASH == vcurrent_hash())

$ ./v version
V 0.4.10 b9fe26c

$ ./v -v version
V 0.4.10 b9fe26cbf18c746256414ae7a6d09cd80b4fa61d

With a dirty Git worktree (C.V_COMMIT_HASH != vcurrent_hash())

$ ./v version
V 0.4.10 8877fe2

$ ./v -v version
V 0.4.10 b9fe26cbf18c746256414ae7a6d09cd80b4fa61d.8877fe2

[huly-for-github]

Connected to Huly®: V_0.6-22847

[spytheman]

I do not understand what problem is that solving?

Can you please answer in more details what is the previous behavior that you observed, what is the new one, that you want it to have, and why do you think it should change?

[lcheylus]

In vlib/v/util/version/version.v, the comparison build_hash == vcurrent_hash() (line 9) is incorrect:

• build_hash length=50
• output from vcurrent_hash(), length=7

If build_hash == vcurrent_hash(), full version must only return vcurrent_hash() (long form), the second part (short form for commit hash) is unnecessary in this case.

[spytheman]

Perhaps there is a misunderstanding - I can read the diff just fine, and I am not asking you about it.

I am asking about the observed behavior before,
the wanted behavior after, and why do you think it is better that way.

Those are questions that I can not answer by just reading the diff in general.
Sometimes, that is possible, but not always.
However the code for the version hashes is a bit subtle, and important for bootstrapping and other tooling, and so I prefer to understand your motivation/context better.

[spytheman]

Sometimes that context is revealed by additional tests, but that is not always possible, or it can be difficult to reproduce the original problem without a lot of setup work.

Sometimes the context can be in an issue, that describes in more details, what you tried to achieve/wanted and what prevented you from that.

[lcheylus]

I don't quite understand your questions but I will try to explain my logic with that fix.

• When I'm working on PR v.util.version: fix output when VCURRENTHASH not defined #24264, I have doubts about the comparison build_hash == vcurrent_hash() in full_hash() function.
• After some code digging, I find your commit 37c3f65 to centralise the use of @VCURRENTHASH.
• After debug, I discover that the comparison between build_hash and vcurrent_hash() is ALWAYS false ; and found that there is an issue with length of strings.

I'm just trying to fix an comparison ALWAYS false.

If you think that is better to keep the full version as build_hash.current_hash for all case, then the wrong code must be removed.

Personally I think it's better to have only build_hash for V full version if C.V_COMMIT_HASH == vcurrent_hash()

[spytheman]

The linked #24263 and #24264 are the context that I needed.
Thanks.

[spytheman]

If you think that is better to keep the full version as build_hash.current_hash for all case, then the wrong code must be removed.

I think that such changes should be done after careful consideration about the observed behavior, and given that you did not provide the before/after comparisons, but did at least point out the previous issue (indirectly ...), I will need to read it in more details, and do the before/after observations myself, before approving or rejecting this PR.

[spytheman]

Before (on master):

The output of ./v -v version is V 0.4.10 b9fe26cbf18c746256414ae7a6d09cd80b4fa61d.b9fe26c i.e. it has the full hash of the parent commit (the one from vc/v.c) and the shortened hash of the current v version (the one from the current working copy/latest git commit).

In this case, they are the same (the part after the . is just a shortened version of the longer hash).

After (here):

The output of the same command: ./v -v version, after bootstrapping, is now: V 0.4.10 8877fe2c74f25f05fe871f1b793576ce8a3141fa ,
i.e. now it shows only the full hash, without the shortened version, and without the . .

The same behavior is observed, if the .git/ folder is renamed/removed (simulating the effect of producing a .zip release and using it on a user machine):

[spytheman]

The new behavior is closer to the observed behavior of the .zip/release versions (only showing the full hash).