Git help thread

[Nash]

I added some tags to GZDoom-GPL and now when I build the executables, I no longer get the commit number appended to the version string (for example, in the INI, it says GZGZPL-2.3.2 instead of GZGZPL-2.3.2-xxxx-yyyyyyyy (x is the build number and y is the commit ID). What did I do wrong?

[Rachael]

When you build on a tag, you will not see those numbers.

Go into your repository and do "git describe --tag". This is by design, and ZDoom actually takes full advantage of this for real release versions. (The commit numbers are confusing as fuck if you have no idea what git is or how it works, so for regular releases it actually makes sense to leave them out)

You can tag your history to alleviate this problem if you'd prefer your tags to appear commits back.

Or - just make your first post-tag commit. You will then have a tag that says v2.3.2-1-xxxxxxx.

[Nash]

When doing a Pull, is there a way to only do the merge up to whatever Tag Graf added last (let's say 2.4pre), instead of anything past beyond that? My idea is to merge only up to the most recent tag, build and release an official version of GZGPL, and THEN continue with the devbuilds.

Sneak edit: I am dumb and just realized I've already asked this before and answered it myself even

[Rachael]

This is tricky, without messing up your own repository.

However, if you want all of Graf's tags, you can do this:

Code: Select all • Expand view

git fetch -t https://github.com/coelckers/gzdoom
git merge tags/g2.3.2
git push --tags

If you do not want all of Graf's tags, it gets a lot more tricky:
First, you need to find out what commit ID the tag is on. In the case of g2.3.2 the SHA-1 is a1026ff03762bd30f0e5f5e076c7acdd46b819c3 - so -

Code: Select all • Expand view

git fetch https://github.com/coelckers/gzdoom
git merge a1026ff03762bd30f0e5f5e076c7acdd46b819c3
git tag -a gpl2.3.2
git push --tags

[Graf Zahl]

This stuff is actually a lot easier with a GUI frontend, you fetch the repository you need to work with, make sure you checked out the head of your branch and then pick the tag you want and merge it it. This can become quite messy with the command line if you do not precisely know what to do.

[Major Cooke]

Two such recommendable guis are GitKraken or SourceTree.

[Rachael]

Most people use TortoiseGit, anyway.

[Graf Zahl]

I can't stand SourceTree, I had to deal with it too much on my work Mac, TortoiseGit is a lot better and far more straightforward to use.
And at some time they added mandatory registration when I stopped upgrading because I saw no point in that.

[Rachael]

I do post command-line git commands for a very good reason, though:

First, it's worth it to learn them, period - they offer a flexibility you just cannot find in most GUI's.

Second, and most important - they are universal. No matter what Git program you have installed, they will work the same with all of them (since GUI gits all fork from the mainline Git, anyway). I dare not make assumptions that Nash, for example, has TortoiseGit installed - because if I am wrong then the instructions that I post for him will be incorrect, also.

[Nash]

Thanks Rachael... I'm using TortoiseGit but I figured it out based on your instructions, it was straightforward to translate for the most part. :D

So what's up with the red X's on the Github lately? It says "AppVeyor build failed" on all of them.

[Graf Zahl]

I registered the project for AppVeyor, but so far haven't managed to set it up properly so that it can build successfully, because I got sidetracked by some more pressing issues. It would be nice if someone who already had some experience doing this stuff could help out, because right now there's more important things I have to deal with than setting up the environment

[Gez]

Not exactly Git help, but I'm not sure whether it's a bug or not and it's the most appropriate thread for compilation issues I think. Using GZDoom git commit cfafbfe4f2284a047babd457ac914e79ff82ea14, I get those:

---

CMake Error at CMakeLists.txt:210 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:211 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:212 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:213 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:214 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:215 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:216 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:217 (string):
string sub-command REPLACE requires at least four arguments.


CMake Error at CMakeLists.txt:218 (string):
string sub-command REPLACE requires at least four arguments.

[Edward-san]

Are you sure you changed nothing about the CMake program, like an update? The code indicated by the errors is there since 2008...

[Gez]

had an oooooooold CMake that didn't know about Visual Studios newer than 2008, so I deinstalled it, installed the latest stable fresh from the CMake page (that would be 3.), and ran it on a pristine, new, devoid of any remaining old file, GZDoom directory.

I got rid of the error by deleting the offending lines, and then a quick grep through the entire directory found a single instance of /GR, in re2c, just after a comment saying that RTTI is required. So whatever, it's late and as long as things stop inventing dumb pretexts for not working I'm happy.

[Nash]

When you go back to some old commits and "reset master to this" using TortoiseGit ... are the future commits truly wiped? So if I reset, then do a new commit from that point, that other stuff is gone for good right?