For those who have never used git, like me up until like 30 minutes ago, a good place to learn is Learn.GitHub. They have both video, and text on how to do many of the common things you'll be using in git.
We should adopt this as a whole to make sure every one is working on the same code base.
If checking out in cygwin, but in windows... It's a real PITA to have all those LF files sitting around. Before you do a pull, put this in cygwin.
git config --global core.safecrlf true
This makes Cygwin convert LF files to CRLF on pull, and back to LF on commit (LF is the standard storage format with git). (it will warn if it's trying to convert a binary file.. autocrlf will do it automagically no matter what).
could that be due to different EOL's?
I use ultra edit which automatically detects EOL types and then sticks to that, so i thought that wouldn't be a problem. But now I wonder ...
We gotta be sure to all use the same anyway like dustin said.
maybe that's also why I couldn't pull and apply the changes from my forked prism earlier on.
This last time I pushed it straight from my computer to dygears repo instead. github then doesn't do a merge check for you, so 'it just works'.
I think that CRLF would be best as it works on all platforms, and we should save the files in the UTF-8 encoding. (Kinda like saying anal sex is the best because it works on all genders.)
We should also use long open tags for PHP. I know it's an INI option, it's just another thing that can confuse someone who has that option set to off. And again, "<?php" will always work where as "<?" only works some of the time. The code should be a portable as possible.
I guess we should write up a programing style and standard for PRISM.
Dygear... Git automatically converts files to LF. Hence why the autocrlf config option I suggested is a good idea. upon clone, it goes to CRLF, and on commit, converts back to LF.
I don't get git ...
If I pull the "read only url" mentioned on github shouldn't that include the packetFix and udp branches? git branch does only list master.
No, git will only pull branches - not entire collections of branches, or whole repositories.
Normally it's good to start with cloning the master branch of a project. Or in fact, fork it first to your own account on github and then clone your own master branch from your fork to your programming computer. You create your own fork to be able to push changes you made to github. You don't normally have write access to a repo unless it's yours or unless the owner has added you a collaborator.
Then you create a new branch (on your computer) on which you will be working, leaving your master branch untouched.
From there on you can do lots of things. You can make your own changes in your new branch and when done, push that new branch to your own repo on github. Your repo will then have a master branch and that new branch. You then tell the original repo owner that you have a patch (in the new branch on your fork) which can be pulled (send a pull request via github).
But now say you have cloned the master branch of prism and want to pull in new changes made by someone else, on another branch. You want those changes applied to your current dev branch. What you then simply do is first make sure that you are in the correct branch at home (git checkout dev). Remember not to use the master branch. Then made sure that you do not have self-made changes not-yet-commited in that branch. If so, commit them first. Then you pull in the branch that you want the changes of (git pull <giturl> <branchnamewithchanges>). Your dev branch at this point will have all the changes made from the other branch.
get it?
So you only transfer branches and not entire repo's. You're basically only interested in a certain line of development, not all the patches made for one project. Imagine a big project - you would not want all the experimental branches from people - you really only want the branches that you know are worth something to the program and you. So you get the master branch (you always want that, well normally you do), create your own development branch off of that and then you see if you want to pull interesting other branches, into your own new development branch.
Now I git it. I watched the video at learn.github.com and he was talking about "when you checkout the database you get a clone of the entire databast". But apparently it's just the master in that case.
yeah I think what they might mean with 'entire' is that git will remember all the changes made to a branch. So you get the entire commit and merge history of a branch.
eg. http://github.com/Dygear/PRISM/commits/master/
Or do a 'git log' on your cloned master branch on your computer. You'll see the same listing. I think you can actually revert your branch to any of those previous commit states even. git remembers all that.
Or maybe they just mean that by cloning a branch you get all the files of the project (the entire project) with just one command. But the entire project is always in one branch. You can have other branches of the same project but you can see those as copies of the master branch (directly or indirectly) - copies of the entire project.
But when you clone for example PRISM, you just get the master branch. You will have to manually pull the other branches you want to have. Just take care you don't pull (which means fetch and merge) them into your master branch It's one of those things you have to remember to always check before pulling and pushing; which branch am i in and have I still to commit any changes I may have made in that branch?
Still fighting with git on the windows side of things.
C:\Documents and Settings\Mark Tomlin\PRISM>git pull origin current Enter passphrase for key '/c/Documents and Settings/Mark Tomlin/.ssh/id_rsa': From github.com:Dygear/PRISM * branch current -> FETCH_HEAD Updating 7fc290d..2d61a0c Fast-forward PHPInSimMod.php | 16 ++++++++++++++++ modules/prism_connections.php | 6 ++++++ 2 files changed, 22 insertions(+), 0 deletions(-)
C:\Documents and Settings\Mark Tomlin\PRISM>git checkout current error: pathspec 'current' did not match any file(s) known to git.
C:\Documents and Settings\Mark Tomlin\PRISM>git checkout current error: pathspec 'current' did not match any file(s) known to git.
C:\Documents and Settings\Mark Tomlin\PRISM>git branch * dev master
C:\Documents and Settings\Mark Tomlin\PRISM>
Did I miss something? I pulled current, where is it?
Apparently I have to do this:
C:\Documents and Settings\Mark Tomlin\PRISM>git branch current
C:\Documents and Settings\Mark Tomlin\PRISM>git branch current * dev master
C:\Documents and Settings\Mark Tomlin\PRISM>git checkout current M configs/connections.ini M configs/cvars.ini M modules/prism_packets.php D modules/prism_plugins.php Switched to branch 'current'
C:\Documents and Settings\Mark Tomlin\PRISM>git pull origin current Enter passphrase for key '/c/Documents and Settings/Mark Tomlin/.ssh/id_rsa': From github.com:Dygear/PRISM * branch current -> FETCH_HEAD Already up-to-date.
C:\Documents and Settings\Mark Tomlin\PRISM>git branch * current dev master
C:\Documents and Settings\Mark Tomlin\PRISM>
And that did what I want.
The current recommendation is to them merge current with dev and work on dev until you get to a point where you would like to push your updates to the rest of us. From there you merge back into the current branch, and then push that to the github current branch. That will allow the rest of us to see what's going on.
Vic, do tell me if I missed anything.
It should be noted that I was still having problems with this after, so I ran the following command to see if that helps. I'll let you know the results as they come.
As it turns out, you should of used the `git fetch` command as explained here:
Agreed, I'm still getting used to it. But even with some of the head aches, its still quite invaluable. There is no way we would of been able to have us three currently working on this without github. At least it does most of the merges for us.
yeah hummm So atm it's all in unix line endings (LF), which I'm personally fine with, but when windows users open an ini file in notepad, it's unreadable.
So like you say, we have to find a way to keep things, or releases at least in CRLF format. That means we all have to work in CRLF format as well I guess, or at least save them like that.
