Appending github Commit Number to Mod Version

[Bartimaeus]

There are a number of people good with github here - I am not one of those people. Basically, the idea I'm wondering is if there's a way to automatically have the mod version number update to the latest commit number? For example:

VERSION ~V4 Beta 10~

...->

VERSION ~V4 Beta 10 (%Commit Number%)~

...where "%Commit Number%" is simply whatever the latest commit number is from when they downloaded it. That way, when someone posts their weidu log, you can see the exact version of the mod that they downloaded from github if you're the type of person that makes a number of changes before officially incrementing a new version number. I did some cursory searches, but didn't find anything too related to what I was looking for.

[jastey]

I see what you mean, but: do not download the master. Always download the latest tagged release.

Because the master is usually an untested and probably unstable interim version until the next release. And if you play with one of those, I honestly do not care which commit number gives you problems.

[Bartimaeus]

3 minutes ago, jastey said:

I see what you mean, but: do not download the master. Always download the latest tagged release.

See, I recommend people do the opposite for my mods, because I'm not going to increment a version number for every last little minor bug fix I commit to the latest version...and I only commit things when I believe they are working (...which hasn't been true a couple of times over the years, but overall, not a bad record).

Edited April 3, 2020 by Bartimaeus

[AL|EN]

@Bartimaeus I'm afraid It's impossible: the commit's SHA-1 hash is calculated over the whole repository snapshot including each file, so to calculate the commit's hash you need to know the contents of all the files which contains the future hash itself.

12 hours ago, Bartimaeus said:

I'm not going to increment a version number for every last little minor bug fix I commit to the latest version.

But that is what version number is for - to indicate code changes, no matter how small, even typos. The 3-digit scheme which some mods uses can be easy adapted to "Semantic Versioning" - MAJOR.MINOR.PATCH.

My only suggestion would be to increment last digit of the version number with every commit. The version number of 1.2.7 could quickly endup as 1.2.321 but who cares if it provide you the information which you require in order to debbug bug reports? There is an git build-in automated way to do it, wana try?

[Bartimaeus]

If I was doing it that way, I guess I'd have to get rid of displaying the final number anywhere but the version field, since that'd get so annoying to keep updating elsewhere. Sure, tell/link to me how!

@The hash: Ahh, I thought the commit number...was...derived from the change itself, but it being a hash of the entire thing makes a lot more sense and does make it impossible, yeah.

Edited April 4, 2020 by Bartimaeus

[AL|EN]

@Bartimaeus Correct me if i'm wrong, this is the version 'scheme' which you want to increment:
 

VERSION ~v4 Beta 18 (Revised V1.2.3)~

 

[Bartimaeus]

13 minutes ago, AL|EN said:

@Bartimaeus Correct me if i'm wrong, this is the version 'scheme' which you want to increment:
 

VERSION ~v4 Beta 18 (Revised V1.2.3)~

 

Yeah, sure.

[AL|EN]

1. Enable "Show hidden files" for you OS
2 .Go to IR_Revised-master\.git\hooks and make a copy of the file "pre-commit.sample" as "pre-commit" (without file extension)
3. Replace the content of the "pre-commit" file with below code, save the file.

#!/bin/sh
tp2path="item_rev/item_rev.tp2"

OLDVERSION=$(grep 'VERSION ~' $tp2path | cut -d'(' -f2 | cut -d')' -f1 | awk -F 'Revised ' '{ print $2 }')

REGEX0="(v|V)([0-9]+).([0-9]+).([0-9]+)"
REGEX1="([0-9]+).([0-9]+).([0-9]+)"

if [[ $OLDVERSION =~ $REGEX0 ]]; then

      vChar=${BASH_REMATCH[1]}
      major=${BASH_REMATCH[2]}
      minor=${BASH_REMATCH[3]}
       path=${BASH_REMATCH[4]}
    newpath=$(($path + 1))
    NEWVERSION="${vChar}${major}.${minor}.${newpath}"

    echo "Old version: $OLDVERSION"
    echo "New version: $NEWVERSION"

    sed -b -i "s/Revised ${vChar}[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+/Revised $NEWVERSION/gI" $tp2path

elif [[ $OLDVERSION =~ $REGEX1 ]]; then

      major=${BASH_REMATCH[1]}
      minor=${BASH_REMATCH[2]}
       path=${BASH_REMATCH[3]}
    newpath=$(($path + 1))
    NEWVERSION="${major}.${minor}.${newpath}"

    echo "Old version: $OLDVERSION"
    echo "New version: $NEWVERSION"

    sed -b -i "s/Revised [[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+/Revised $NEWVERSION/gI" $tp2path

fi

git add $tp2path

exit

4. Modify any file, stage file modifications, create example commit.
5. The VERSION keyword value from item_rev/item_rev.tp2 should now be:

VERSION ~V4 Beta 10 (Revised V1.2.8)~

Note that this solution relays heavy of the above unusual version format so if you change it, it might break.

@lynx Bash code review requested 

Edited April 9, 2020 by AL|EN
fixed

[Bartimaeus]

Seems to work with IR and SR, thanks!

[lynx]

It's not how I would've done it, but since it works, that matters even less.

[AL|EN]

@Bartimaeus It turns out that when 'sed' command is used via Git Bash, it replaces end line characters from CRLF to LF. I fixed the above code but you will have to replace you local code by yourself.

EDIT: Well, removing 'V' from the version break the script. Changed the code to ignore this.

@lynx Do you know a nice replacement for sed which doesn't replace line endings and can handle regex-based replace?

Edited April 8, 2020 by AL|EN

[Bartimaeus]

10 hours ago, AL|EN said:

@Bartimaeus It turns out that when 'sed' command is used via Git Bash, it replaces end line characters from CRLF to LF. I fixed the above code but you will have to replace you local code by yourself.

EDIT: Well, removing 'V' from the version break the script. Changed the code to ignore this.

@lynx Do you know a nice replacement for sed which doesn't replace line endings and can handle regex-based replace?

I did notice I was getting yelled at every time I made a commit now by SmartGit for that. Thanks, .

[Bartimaeus]

I tried to implement the new version with IRR, and it no longer seems to work.

Smartgit says this when committing:

C:\GitHub\IR_Revised> git.exe -c "credential.helper=C:/Program\ Files/SmartGit/lib/credentials.cmd" rm -- "item_rev\settings - Copy.ini"
rm 'item_rev/settings - Copy.ini'
C:\GitHub\IR_Revised> git.exe commit --file=C:/Users/BARTIM~1/AppData/Local/Temp/smartgit-5881788229702730413tmp/commit-15882150802797423814.tmp -o -- "item_rev\settings - Copy.ini"
Old version: V1.2.8
New version: V1.2.9
LF will be replaced by CRLF in item_rev/item_rev.tp2.
The file will have its original line endings in your working directory
[master 4db5888] Test versioning again again again again again
 1 file changed, 31 deletions(-)
 delete mode 100644 item_rev/settings - Copy.ini
C:\GitHub\IR_Revised> git.exe -c "credential.helper=C:/Program\ Files/SmartGit/lib/credentials.cmd" push --porcelain --progress --recurse-submodules=check origin refs/heads/master:refs/heads/master
Delta compression using up to 8 threads
Total 3 (delta 2), reused 0 (delta 0)
To https://github.com/BartyMae/IR_Revised.git
  refs/heads/master:refs/heads/master d8dc415..4db5888
Done
'master' pushed: d8dc415..4db5888
Delta compression using up to 8 threads
Total 3 (delta 2), reused 0 (delta 0)

The correctly ECHO-ed "Old version" and "New Version" suggests it's able to find the correct field and knows how to increment it, but it isn't actually taking on the .tp2 itself even after multiple tries. I guess that would suggest there's something not working with the "sed" command (which I'm not familiar with).

[lynx]

Sounds like that -b is causing it, since you're not actually matching any space.

[Bartimaeus]

3 hours ago, lynx said:

Sounds like that -b is causing it, since you're not actually matching any space.

I removed it, still not actually updating the .tp2 to 1.2.9.

Edited April 9, 2020 by Bartimaeus