War-Thunder-Datamine icon indicating copy to clipboard operation
War-Thunder-Datamine copied to clipboard

Split versions

Open klensy opened this issue 4 years ago • 72 comments

Hi. Split prod\dev to different branches, as its hard to see diffs in one branch when they mixed. Tag versions, so you can compare releases directly, for example https://github.com/klensy/wt-tools/compare/v0.2.2.3...v0.2.2.4

klensy avatar May 18 '20 15:05 klensy

Sorry, by prod you mean the live client? I'm not sure what you mean. Only the dev client's updates are uploaded here*, so with what are they mixed?

*EDIT: Not true since 2020-06-15.

gszabi99 avatar May 25 '20 23:05 gszabi99

I reckon it's situations like this that cause complications when checking diffs.

изображение

I used to do revert commits before pushing actual patch changes to maintain change set consistency when I had branch resets for whatever reason.

изображение

But I do like the tag approach more. Though it's a bit more of a fuss when everything's in order, which can be alleviated with a bit of automation.

изображение

VitaliiAndreev avatar May 26 '20 23:05 VitaliiAndreev

Currently these are the git commands I use to automatically push stuff to Github. 2-click git.sh

#!/bin/bash
VER=`cat D:/WarThunder/datamine/char.vromfs.bin_u/version`
git add .
git commit -am "$VER"
git push

How could I modify this to also make tags and assign them to the commits?

gszabi99 avatar May 27 '20 16:05 gszabi99

Try

git tag $VER
git push origin $VER

That should tag the current state of the repo, i.e. the latest commit, and push the tag to GitHub (assuming your local repo uses the "origin" alias for the remote repo).

You can find more info here.

VitaliiAndreev avatar May 27 '20 17:05 VitaliiAndreev

How/where can I check the name? In any case, I assume "origin" is the default one?

gszabi99 avatar May 27 '20 17:05 gszabi99

git remote -v

It will be "origin" unless you specifically changed it. You might have to if you have several remotes to push to - in which case, add more lines.

VitaliiAndreev avatar May 27 '20 17:05 VitaliiAndreev

D:\WarThunder\datamine\GitHub repo\War-Thunder-Datamine>git remote -v
origin  https://github.com/gszabi99/War-Thunder-Datamine.git (fetch)
origin  https://github.com/gszabi99/War-Thunder-Datamine.git (push)

Thank you, so it's origin in my case.

You might have to if you have several remotes to push to

Is a "remote" a local copy of the branch that is on my PC?

gszabi99 avatar May 27 '20 17:05 gszabi99

It's what it says on the tin - a remote repository, i.e. not near you. In your case it's on GitHub (https://github.com/gszabi99/War-Thunder-Datamine.git). What you have locally is, well, a local repository only users on your machine can work with. Somebody else can fork your remote into a new remote, or clone it as a local repository. Local repositories need to be synced with their remotes to stay up-to-date if there's more than one contributor.

If you create a repo on, say, BitBucket, you might need to push to both to keep them updated. Some sites (like GitLab) have a mirroring functionality that nicks any new commits from a specific remote.

The local-remote model applies to branches the same way it does to repositories.

VitaliiAndreev avatar May 27 '20 17:05 VitaliiAndreev

Thank you for the lengthy explanation. So I believe the example you gave here is going to work for me, as I only upload them to GitHub and I'm the sole contributor.

git tag $VER
git push origin $VER

gszabi99 avatar May 27 '20 17:05 gszabi99

You're still going to need the version number, but the script that you've got already covers it.

VitaliiAndreev avatar May 27 '20 18:05 VitaliiAndreev

Strange, in 1.99.0.21 something triggered rebuilding all your png files. I checked few source ddsx - they didn't changed at all.

klensy avatar May 28 '20 12:05 klensy

Yes, I was perplexed as well. I have no idea what caused it, we shall see if it's also going to happen next time.

gszabi99 avatar May 28 '20 12:05 gszabi99

Only thing that changed in pngs (not source ddsx) is create and modify ext info. I've saw this few times in your repository. Try to change your dds to png convertor to not to write this info.

klensy avatar May 28 '20 12:05 klensy

I use ImageMagick's mogrify tool, and I don't think I have such an option.

gszabi99 avatar May 28 '20 13:05 gszabi99

try -define png:exclude-chunk=date

klensy avatar May 28 '20 13:05 klensy

You tried that IM option? It works. Master branch without latest commits, try to add git push origin master after last line, maybe it will fix this issue. It's fun: you wrote about romanian eula, but it absent from commit history, check @VitaliiAndreev repo for example.

klensy avatar May 29 '20 01:05 klensy

Nope, it doesn't want to work. Many dds files were not converted by this, while with the -format png I used earlier, they were. For example the entirety of the atlases/medals and atlases/units folders remained dds.

gszabi99 avatar May 29 '20 08:05 gszabi99

Didn't remove -format png, just add that line.

klensy avatar May 29 '20 08:05 klensy

Same result with -format png -define png:exclude-chunk=date. Lots of missing pngs.

gszabi99 avatar May 29 '20 08:05 gszabi99

You tried that IM option? It works. Master branch without latest commits, try to add git push origin master after last line, maybe it will fix this issue. It's fun: you wrote about romanian eula, but it absent from commit history, check @VitaliiAndreev repo for example.

So I should push twice?

gszabi99 avatar May 29 '20 08:05 gszabi99

Try manually git push origin master to see if it fix the things. What exact command you use to convert? ./magick mogrify -format png -define png:exclude-chunk=date a-20g.dds works good. Or send files that fails.

klensy avatar May 29 '20 08:05 klensy

MOGRIFY -format png -define png:exclude-chunk=date "D:\WarThunder\datamine\monitor\atlases.vromfs.bin_u\medals\*.dds" > NUL in a batch script.

gszabi99 avatar May 29 '20 08:05 gszabi99

MOGRIFY -format png -define png:exclude-chunk=date "D:\WarThunder\datamine\monitor\atlases.vromfs.bin_u\medals\*.dds" > NUL in a batch script.

Used this command, all good.

Version: ImageMagick 7.0.10-14 Q16 x64 2020-05-23

klensy avatar May 29 '20 09:05 klensy

Version: ImageMagick 7.0.10-6 Q16 x64 2020-04-06 Maybe this could be the problem?

gszabi99 avatar May 29 '20 09:05 gszabi99

I really don't know. You can send me files that didn't converted.

klensy avatar May 29 '20 09:05 klensy

Oooooookay, this problem runs waay deeper than I ever imagined. Tried to manually go through the steps, and of course I ran into a problem. Using the wt-tools_windows-2019/ddsx_unpack.exe (v0.2.2.2), it fails because of the oodle compression type. Which is funny, as until days ago it had no problem unpacking them in a script.

gszabi99 avatar May 29 '20 09:05 gszabi99

Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D

gszabi99 avatar May 29 '20 09:05 gszabi99

Nope, doesn't want to work even through CMD. Strange, just yesterday it worked without a problem.

gszabi99 avatar May 29 '20 09:05 gszabi99

Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D

Don't work how exactly? There should be some errors printed in console.

klensy avatar May 29 '20 09:05 klensy

Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D

Don't work how exactly? There should be some errors printed in console.

unsupported compression type: oodle

Very strange, just yesterday it worked flawlessly.

gszabi99 avatar May 29 '20 09:05 gszabi99