First go to www.gitorious.org and set up an account over there. Then ask someone who is already part of uclales-dev to add you to that group. Now you could edit all the repositories. There is one master repository that represents the main code, and one branch per developer where everyone is free to do in what he wants.

Of course, other peoples branches should normally not be touched, and the master branch with much care, that is, for bugfixes and clear features that are well developed only.

Pushing code to gitorious goes best over ssh, and to get that working smoothly you can add your ssh key (located in ~/.ssh/id_rsa.pub ; possibly you have to run ssh-keygen  first) to your gitorious profile.

Once you have completed your gitorious account, you can get the code by typing      

git clone git@gitorious.org:uclales/uclales.git    

at the command line. This gives you the master branch in subdirectory uclales. If you prefer to clone the repository in a different dir, then append this dir name to the command. Now go to this subdirectory. Any git command you want to apply on your repository needs to be done from somewhere within this subdir.

Now, let's look at the different branches that are available. Just after the cloning, only the master branch is available in the local repository, but in the remote repository there are already a few branches available. So type: git branch -a    

to see all branches. The local branches are shown first, and the remote branches after that.

If you want to switch to a different branch that is already present in the remote repository, the first time you type:  git checkout -b <newbranch> origin/<newbranch>   

This means that you make a local branch with the name <newbranch> which tracks the remote branch origin/<newbranch>, which whom you communicate through git pull  and git push. Note that origin is a tag that points to the address that you specified in git clone  when you created the repo.

After that, changing branches can be done with: git checkout <branchname>   

If you want to know which branches are now available locally, type in: git branch. At this stage, you should see 2 branches: The master branch and the <newbranch>  branch you just created. The one with a star in front of it is the active branch. Changes you make in the code will apply only to this active branch.

There are two possibilities to insert your non-gitted version into our repository. One is when the changes between your code and the current master are few, one is when there are many changes.

Assuming that the code looks similar to the master, you can create a new branch from the master with git checkout -b <newbranch>  master. In the UCLALES repository this has already been done for the current main developers. Now copy the files you've altered from your old source dir into the git repository; include all the files you're not sure whether you've changed them. Git will find out about what's changed and what is not. Check whether the resulting code actually works. At the very least, ensure your code still compiles. If so, then you are ready to commit your initial version to the git repositories.

If your code is quite different from the master, and there is also no other branch in the code that is similar, it is probably best to do a manual merge outside the git repository. So create the new branch like described above (if necessary), but do not copy any files directly into the git working dir. Instead, use a merge tool like kdiff3, meld or xdiff to compare file by file the differences and merge the two codes. This usually works with something like:     <mergetool> <private-code-dir> <git-code-dir>. This should give you an opportunity to review the merge on a case-by-case basis, and decide to take either your private version or the one that is already in git. After this manual merge, the code in the git working dir should be the code you want to work with. Try this out, at least by compiling the code. You are now ready to commit your initial version to the git repositories.

Now the local repository is up to date with your changes, you need to synchronize with the remote repository. This is done with git push

The man pages of git are not very clear sometimes, but they are quite exhaustive. Be sure to give them a look.

Updating your local repository with remote changes goes with git pull:  

git pull origin <branchname> to update just one branch, or just git pull to update everything (in the default settings).

If you want to commit your changes to your (local) repository, type git commit -a   

and describe what you are changing in the commit file. It is advisable to only commit if a feature/bug fix is in principle complete, and especially to keep the code in the repository compilable at all times. Putting stuff in the remote repository goes with git push.

If you want to check what has been changed since the last commit, use git status and git diff (or git diff-tool for the graphically inclined)  

Adding files and directories to git goes with: git add 

Also, removing from and moving inside the repository needs to be done carefully: Use git rm or git mv for that.

If you screwed up the code during coding, and did not commit any changes yet, you can reset your files to the latest state using: git checkout -f   

If you just want to restore the original state of file LES.f90, do: git checkout -f LES.f90   

If you want to merge the changes of branch1 into branch2, do: 

git checkout <branch2>   

git merge <branch1> 

If there are merge conflicts (could also happen with a git pull ), then you can use ;git merge-tool to resolve the conflicts manually.

If you screwed up the code and want to get back to the way it was after your last commit, type git reset --hard HEAD   

A faulty commit can be reset with git reset -soft HEAD^    

See the man page of   git-reset  for more information of the use of   --soft. In general, be careful with reset and especially reset --hard, since it can confuse the history of the commits. Never ever use reset --hard to get rid of commits that are already pushed to the main repository. To remove an earlier commit, or a commit that has already been pushed to the remote repository, you should use git revert <commit-number>. To make revert work, you need a clean HEAD, so you should either git commit - a  all your current results, or git reset --hard HEAD your working dir to the latest committed version first.

To remove all files and directories that are not tracked by git from the current dir, use git clean -d -f   

Finally, a few graphical tools are available to play with if you like:    git gui ,   gitk  should at least be there.