Page 3 of 5

Re: Nash's SVN -> Git thread

Posted: Tue Aug 20, 2013 1:08 pm
by 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.

Re: Nash's SVN -> Git thread

Posted: Fri Dec 27, 2013 8:34 am
by 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?

Re: Nash's SVN -> Git thread

Posted: Sat Mar 01, 2014 8:28 am
by 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?

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Sat Mar 01, 2014 10:42 am
by 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.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Sat Mar 01, 2014 10:52 am
by Nash
I'll see what I can find with Git Extensions.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Sat Mar 01, 2014 10:57 am
by 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.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Wed Mar 26, 2014 11:14 am
by 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

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Wed Mar 26, 2014 11:35 am
by 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.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Mon Apr 28, 2014 10:23 am
by 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
Gez wrote: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/

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Mon Apr 28, 2014 1:28 pm
by Gez
Thanks, that'll come in handy.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Fri May 02, 2014 10:36 am
by 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...

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Fri May 02, 2014 10:42 am
by Gez
Nash wrote:Should the individual fixes be commited separately?
I'd go with that, personally.

Re: Git help thread (prev. Nash's SVN -> Git thread)

Posted: Fri May 02, 2014 10:49 am
by edward850
Gez wrote:
Nash wrote: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. :P

Re: Git help thread

Posted: Fri May 02, 2014 11:51 am
by 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.

Re: Git help thread

Posted: Tue Feb 16, 2016 3:53 am
by 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!