ENIGMA Forums

General fluff => Announcements => Topic started by: RetroX on January 06, 2012, 05:45:49 PM

Title: New GitHub Repository
Post by: RetroX on January 06, 2012, 05:45:49 PM
I've just set up a repository on GitHub for ENIGMA. You can find it here: https://github.com/enigma-dev/enigma-dev

If you're running a Linux-based distro, you can install the git package, then run the following command to create a local copy:
Code: [Select]
git clone git://github.com/enigma-dev/enigma-dev.git(note: git checkout is not like svn checkout; git clone is svn checkout)

For those of you that want something like TortoiseSVN, TortoiseGit (https://code.google.com/p/tortoisegit/) is also available. If you don't know how Git works, I'd suggest learning it (it's not the same as SVN) or asking someone how to use it.

From GitHub, you can fork the repository (and then push changes in your fork back to us), submit bugs (either there or on flyspray here), and watch for changes. You can also view a list of files and commits with much more ease. If you want to download a copy of the repo at any time, GitHub also supports this: https://github.com/enigma-dev/enigma-dev/downloads

One of the largest differences between Git and SVN is Git's naming of commits; instead of using incremented numbers, it uses hashes. Commits can be named using tags (git tag <name> <commit>), and you can switch to a specific tag or branch with (git checkout <tag/branch>). Git also makes a single .git directory in the root instead of SVN's recursive .svn nonsense.

Note that the SVN repo is still up, but I'm not entirely sure of how things are going to work with either.  This is a very large change, however, is really for the better.
Title: Re: New GitHub Repository
Post by: Rusky on January 06, 2012, 05:47:56 PM
git clone is closer to a remote svnadmin dump actually :P
Title: Re: New GitHub Repository
Post by: RetroX on January 06, 2012, 05:52:32 PM
git clone is closer to a remote svnadmin dump actually :P
Except, it works with compressed objects, not raw files.
Title: Re: New GitHub Repository
Post by: TheExDeus on January 06, 2012, 08:41:34 PM
Soo how exactly committing changes will work? In SVN it was extremely easy.. I suspect it will be as easy in GIT too? For example, I am on Win and want to have a GUI program (its just nicer) to commit a change to the repository. What steps would I use?
Title: Re: New GitHub Repository
Post by: RetroX on January 06, 2012, 09:09:27 PM
Soo how exactly committing changes will work? In SVN it was extremely easy.. I suspect it will be as easy in GIT too? For example, I am on Win and want to have a GUI program (its just nicer) to commit a change to the repository. What steps would I use?
TortoiseGit is designed like TortoiseSVN with a very similar interface, intended for git instead. I don't quite know how either works, but I'll explain the main difference between git's committing and SVN's. Git has more options, but you can still commit in what's mostly the same way as SVN.

SVN commits are centralised, meaning that you have to send the commits to the central server for them to count. SVN only has one way of committing: you can add files that haven't yet been versioned (which will then make them versioned) and then commit, which will commit all modified or newly versioned files.

Git operates on a series of local repositories. This means that with Git, you "clone" the source repository, mess with it however that you want, and then push all of your changes to the destination repository. Through this process, you can make as many commits as you want, amend your commits, and even uncommit what you've done. However, once you move the changes to the destination repository, you're pretty much stuck with those commits. If you uncommit or amend things that are already on the destination repository, you'll have a hard time getting the repository to actually push new changes, because the changes don't match.

Git commits operate as staged and unstaged changes; essentially, anything that you've changed but haven't "staged" won't actually be committed. For example, if I modifed file1 and file2, which are versioned, adding a new commit won't commit those changes that I've made unless I explicitly ask for it (that's SVN's behaviour; you can still do this if you want). You also have to add new files, like SVN. Note that if you modify or delete a file after you stage it, those changes won't be applied until you stage it again. Once you commit something, you have to send it to the destination repository for it to actually be "committed" to the overall repository.

I'm assuming that things like TortoiseSVN and TortoiseGit already support a mechanism for "commit all," which will essentially just stage everything, commit, and push to the master repo, with a given commit message. Git largely replicates the functionality of SVN, although, it has a lot more features and operates slightly differently. It's also a lot faster and compresses things, making it easier and faster to pull from the remote repos.
Title: Re: New GitHub Repository
Post by: TheExDeus on January 07, 2012, 05:56:52 AM
We will see how this goes. I didn't like that I will have problems committing conflicted data, or that I can't revert changes when I move everything in the destination repository, but maybe I just didn't quite clearly understand. It was easy for me to understand SVN as it has only one button - Commit. You choose the files you want to commit, write a description of the changes and sit back (takes a few seconds to finish). I don't really need new "features" in this process, so I was fine with it before.
Title: Re: New GitHub Repository
Post by: RetroX on January 07, 2012, 11:04:05 AM
We will see how this goes. I didn't like that I will have problems committing conflicted data, or that I can't revert changes when I move everything in the destination repository, but maybe I just didn't quite clearly understand. It was easy for me to understand SVN as it has only one button - Commit. You choose the files you want to commit, write a description of the changes and sit back (takes a few seconds to finish). I don't really need new "features" in this process, so I was fine with it before.

I probably didn't explain that properly.

What I meant is that the git equivalent of "svn checkout" is really a complete clone of the repository. This means that you can check back older revisions without downloading any new stuff, and you can commit/uncommit/amend commits as much as you want before you push it back to the origin repo. The problem with this is that, for example, you clone the repo and then uncommit something that's already on the dest repo, it'll give you a bit of trouble. But in most cases, people won't want to (or even know how) to uncommit something or amend a commit.

In svn, the default is to commit ALL changes to the server, whereas in git, the default is to not commit any changes unless you specifically say so (allowing you to selectively commit files). If you just want to commit everything, git supports that, too.

The new features can be made transparent to most users, but can be made very useful to other users.
Title: Re: New GitHub Repository
Post by: Rusky on January 07, 2012, 12:44:48 PM
Quick conversion guide:

"svn checkout" sets up a local repository, linked to the server you checkout from.
"git clone" sets up a local repository with the entire project history (don't worry, it's fast), linked to the server you clone from.

"svn add" tells Subversion to start tracking a file.
"git add" does tell Git to start tracking a file, but its primary usage is to tell Git to put a file's current state in the "index" or "staging area", a kind of scratchpad for the next commit. Use it right before you commit.

"svn update" downloads new changes from the server and applies them to the working directory.
"git pull" downloads new changes from the server and merges them with your local commits.

"svn commit" finds modified files and sends the diffs to the server with your description.
"git commit" takes what you've "git add"ed to the index and stores it with your description. Using the -a flag like "git commit -a" adds all tracked files to the index before doing this.
"git push" sends new local commits to the server.

Basically, Git splits a few of the steps you're used to in Subversion so that useful things can be inserted between them. The Subversion workflow of "svn checkout; edit; svn add; svn update; svn commit; ..." becomes "git clone; edit; git add; git commit; git pull; git push; ..." You can use "git gui" or TortoiseGit instead of the command line if you like.
Title: Re: New GitHub Repository
Post by: Josh @ Dreamland on January 07, 2012, 04:05:16 PM
You buried my neat shit. >:(

(http://dl.dropbox.com/u/1052740/enigma/screens/renders/AST_Gneration/added_unary/AST_32.svg)
Title: Re: New GitHub Repository
Post by: notachair on January 07, 2012, 05:45:18 PM
Also, if you are on Linux or OS X:

Code: [Select]
git config --global core.autocrlf input
And Windows:

Code: [Select]
git config --global core.autocrlf true
Deals with newline issues when working across different OSes.
Title: Re: New GitHub Repository
Post by: RetroX on January 07, 2012, 06:16:41 PM
Also, random thing that I found out the hard way:

If you're just interested in getting the latest revision (no version control), you can run:
Code: [Select]
git clone git://github.com/enigma-dev/enigma-dev.git --depth 1This will essentially download an unversioned copy of the latest revision.

This will prevent you from downloading all of the commits, which would be pretty big. It has a downside, however, of preventing you from pushing commits to the master repo.
Title: Re: New GitHub Repository
Post by: RetroX on January 07, 2012, 08:10:07 PM
Notice: You'll probably all have to re-clone now that I've removed the versioned binaries from the commit history. The clone size is half what it was, now.
Title: Re: New GitHub Repository
Post by: notachair on January 09, 2012, 04:50:06 PM
This looks like a nice guide - http://rogerdudler.github.com/git-guide/
Title: Re: New GitHub Repository
Post by: IsmAvatar on January 13, 2012, 08:22:59 PM
In addition, LGM is moving to Git as well.
https://github.com/IsmAvatar/LateralGM

EnigmaBot already reflects these changes.

There has still been some debate on what to do with the Auto-Updater, though.

A few pages on the Wiki will probably need to reflect this as well - especially once we figure out what to do with the Auto-Updater.
Title: Re: New GitHub Repository
Post by: IsmAvatar on January 15, 2012, 05:38:07 PM
Thanks to Rusky, we were able to restore many lost svn revisions caused by herp-derping the svn repositories back in the day (adding the trunk/branches/tags folders) and herp-derp-git-importing them without accounting for that. Rusky fixed it, but we had to delete the git repositories and re-create them.

This will probably also mean that those of you who already checked out (cloned) either of the repositories will need to re-clone again, since they both now have a more complete history. Likewise, to anybody who was watching either of the repositories, you will need to re-watch them again.

Hopefully (cross our fingers) this will be the last time we have to do that. I'm sure you all understand - the initial setup/transfer can be a little unstable, but now that we have things going again, it should all be good.



Also, the guide a2h found is amazing. Perfect for my needs.
Title: Re: New GitHub Repository
Post by: RetroX on January 16, 2012, 08:17:58 PM
Random addition to the guide: git stash "stashes" existing changes whereas git stash pop will apply stashed changes. You can do git stash drop to just delete the stashed changes without applying them or git stash apply to apply stashed changes without dropping them. Stashes are stack-based, meaning that you can push several stashes onto the stack and pop them in a FILO (first-in, last-out) manner.

Also, fix the teletype tag. :(
Title: Re: New GitHub Repository
Post by: Rusky on February 01, 2012, 12:54:47 PM
We've removed about 10MB more old binaries and rewritten history, so you'll probably want to reclone again.