Git help thread

[Graf Zahl]

Yeah, just the 2 files that were missing. Not exactly necessary unless you want to edit them from inside Visual C++.

I have no idea why my VC++ Express doesn't want to agree with Randi's full version on file order. It always makes a mess.

[Gez]

Dumb question about the github web UI. I've forked GZDoom. Now if I try to fork ZDoom, it just leads me to my GZDoom fork. Is there a way to force it to create a new ZDoom fork? Do I need to delete the GZDoom fork first?

[Nash]

Is there any way to get TortoiseGit to remember my Github username and password so I don't have to type it everytime I want to Push?

[Graf Zahl]

It is possible but the necessary tool isn't part of the TortoiseGit installation. I had to install Git Extensions to get it, but I can't recollect right now how I had to set it up.
If you ask me, it's rather pathetic that TortoiseGit doesn't do this itself.

[Nash]

I'll see what I can find with Git Extensions.

[Gez]

I'm lazy and I use Github for Windows for commits and pushes, the command line for what can only be done this way, and TortoiseGit for everything else.

[Nash]

Has it always been that, if I pull something from Upstream and if there aren't any conflicts, it silently (as in, I don't see it written anywhere on the screen) commits everything?

This has always been a source of huge confusion for me (and in one case, I had to redo my entire codebase because I didn't know what was going on).

It's confusing because back then on SVN, even if there are no conflicts, I end up with a lot of red exclamation marks that will only go away when I commit, so I'm just used to doing it all manually and seeing things at every step... but with Git it's just weird... :S

[Graf Zahl]

No, it should behave exactly the same, a commit should only happen if you perform one. Og course it can't be ruled out that you have turned on some automatic setting.

[Nash]

I found out why pulling automatically commits. Posting this here for future reference.

Pulling is meant to do that... if you don't want it to commit automatically, you use Fetch instead. Source: https://help.github.com/articles/fork-a-repo

Dumb question about the github web UI. I've forked GZDoom. Now if I try to fork ZDoom, it just leads me to my GZDoom fork. Is there a way to force it to create a new ZDoom fork? Do I need to delete the GZDoom fork first?

I ran into a similar situation too. I don't know if you've solved it yet, but I found this page which might be the answer: http://adrianshort.org/2011/11/08/creat ... thub-repo/

[Gez]

Thanks, that'll come in handy.

[Nash]

What's the recommended commit message etiquette or standard?

Back in SVN, I would put dashes before each line of change:

- Changed something.
- Fixed another thing.
- Added stuff.

But on Github, it seems the first line seems to be a headline/title of sorts... it's easy to follow this system if you're working on 1 thing at a time, for example

Fixes to the sound code

For some weird reason, sounds were played at the wrong pitch.

Or if you're fixing one issue, but the changes were spread across a lot of files

Fixed main menu font graphics

- FONTDEFS defined an incorrect font
- Regenerated TEXTURES entries for the fonts
- Cleaned up some stray pixels from the graphics

But there might be a problem if you were fixing a lot of different issues in 1 commit

Fixed a bunch of stuff!

- Fixed a bug in save.cpp that would delete the user's game directory
- Plugged a memory leak in main.cpp that would hard-lock the computer
- Sound was output 10x louder than it needed to be
- Removed annoying screen flashes when the player dies

In the last example, on the Git commits list, seeing the title alone doesn't give a clear idea of what exactly was fixed. So in that situation, what is the best course of action? Should the individual fixes be commited separately?

I know it's kind of a trivial thing but I was just wondering about this, after reading ZDoom's commit list and noticing that not all commits follow the same format...

[Gez]

Should the individual fixes be commited separately?

I'd go with that, personally.

[edward850]

Should the individual fixes be commited separately?

I'd go with that, personally.

It's also makes your life crap tons easier with feature you'll find useful later on, cherry-pick. Or if you need to revert some changes. Or anything else, really.

[Graf Zahl]

In the early days of SVN I made monster commits. But it really is better to commit each time you completed something, even if it's small.

[Nash]

When pulling from my upstream remote (ZDoom or GZDoom), is there a way to pull one commit at a time, starting from the commit that I last previously pulled successfully?

My problem is that when I come back to updating stuff after some time has passed, it just pulls in EVERY change up to the latest commit in upstream and it just gives me a headache because more often than not, my fork will have build errors and it's hard to keep track of which commit produced the build errors...

SOLVED:

1) Fetch (not pull!) all the changes from upstream first
2) Right-click, TortoiseGit -> Merge
3) Select "Commit", and then the [...] button to the right
4) There's the word "master" written in blue to the top left, click that, choose remotes -> upstream and pick the "master" branch to the right
5) You are seeing all of the commits from the upstream. Click on any commit you'd like to merge (click it so that it's highlighted) and just press Ok
6) The "commit" field will now be updated to the specific SHA-1 of the commit you want to merge
7) Press Ok

This will merge your codebase only up to the commit you specifically chose, instead of all the way to the top! Useful if you need to merge little by little and test to make sure it compiles before moving on to the next commit!