Git repository

From TheManaWorld
Jump to: navigation, search

This article is currently under construction

The concept of the features described in this article are currently under construction. This article basically serves as a white board for collecting and sorting the ideas of the developers who are conceptualizing this aspect of the game. So the article might appear incomplete or messy.


git is the name of the program intended to allow a team to work on a set of program sources, keep versions synchrone and make members team work easily known from others. Gitorious and github are websites that provide free hosting of public git repositories. At some point we moved the content repositories from gitorious to github. See this forum topic [1] for reference. (Note server code was transferred to github since it was written) We are using the version control system Git as our main collaboration tool. You can use it to obtain all the sourcecode and content files you need to participate in the development or to create your own fork.

See the wikipedia article about Git and the Git homepage for details about Git.

In TMW wiki, information about Git is still located in several places where you may find contradictory information. We do apologize for that and work hard to let you have a clear information:

  • This page: The actual links to various repositories should be up to date but some information about how to work with it is not.It still contains useful information and GUI's information should be correct.
  • How to Develop also duplicates some info which you can find else where. It will be completely re-written to make it the entry point of the wiki development part.
  • Working With Git contains the most up to date information to use Git with the command line. It is the actual reference that you should follow. It is important to read it even if you plan to use a graphical user interface.

The primary repository

Initial setup

With Git, we'll have one repository for each project. The central repositories through which we cooperate are hosted on github is a friendly website. On github the main repository for each project is called master. Once you click to the master repository, you can see several ways to clone it (the new svn checkout).

We've categorized all projects related to The Mana World, so you can easily see the complete list of The Mana World projects on github. The projects have different forks (clone) URLs for browsing, read-only or developer access. The URL for developer access is called the "push URL", since it allows you to push commits into the repository via ssh. The list below is for your convenience.

Project Read-only URL Atom feed
TMW, TMW eAthena
TMW branding git:// Atom
This repository contains the branding files to turn Mana into TMW.
eAthena server git:// Atom
This repository contains our hacked up eAthena.
tmwAthena Server data git:// Atom
This repository contains the server data developed for the tmwAthena server and used by The Mana World.
TMW tmwAthena client data git:// Atom
This repository contains the data used by The Mana World clients for the tmwAthena server. .
TMW Art git:// Atom
This repository contains some sources for our artwork.
TMW music git:// Atom
This repository contains the music used by The Mana World clients for the tmwAthena server.
TMW website git:// Atom
This repository contains the website of The Mana World.
Manasource: Mana, Manaserv.
Mana client git:// Atom
This repository contains the Mana client sources.
Manaserv git:// Atom
This repository contains the ManaServ server sources .

For the Mana (the client) and Manaserv, look at

Git uses ssh's private/public key authentication for identifying committers. For development purposes just clone the read-only URL, it will automatically switch to the push URL if you have:

  1. Signed up to
  2. Generated a private/public ssh keypair (if you haven't got this already)
  3. Filled in your public key in your account details on GitHub
  4. Been added with commit rights to the repository
  5. Followed the directions in the [How to Develop] page


If you simply git clone the URL without any additional arguments, it will create the repository in a directory called "mainline". This is generally not what you want. Hence, after the clone url, you should pass the name of the directory you want to have created (just like with Subversion):

$ git clone <clone_url> project

If you want to have all projects in one place, you probably want to do something like this:

 $ mkdir tmw
$ cd tmw
 $ git clone tmw
$ git clone eathena-data
or for all of them in one go (after the cd tmw step):
 $ for repo in  tmw tmwdata tmw-eathena tmw-eathena-data ; do git clone git://${repo}/mainline.git $repo  ; done

The way Gitorious works, we can't have one top-level "tmw" project under which we put all these repositories, since they're really separate projects. Gitorious allows multiple repositories for each project, but they are clones of each other (you can only create new ones by cloning existing ones). This allows anybody (not just the development team) to make clones and start hacking on them. Changes can easily be merged from one one repository to another. So instead of all the inconvenience with TMW forks we had in the past, now comes the time to encourage people to clone!

Shallow cloning for non-developers

One of our repositories, tmwdata, has grown quite large cause of its long history filled with relatively large binary files. If you are only interested in getting the latest version, and have no need to be able to push back changes, then you can make a shallow clone:

$ git clone --depth 1 git:// tmwdata

Working with git


All TMW specific repositories have been now moved to github: While the information included here is not false, a more up to date page has been written with the latest information:

Working With Git

You may also have a look to the original documentation at


From now on, a commit is something you do locally. Others won't see your change on Gitorious unless you push it there. You'll notice committing is very fast, and you can commit multiple times before you decide to push. You can also make corrections to your last commit.

Before you start committing, it is important to identify yourself to git, so that it can include the correct authorship information with your commit. You are no longer identified with a username, as was the case with Subversion. You can read exactly how to do this, as well as other useful information geared towards people switching from Subversion, on this page:

Sample commit message:

 This is the title. Keep this line short.
 This is a longer description of the commit, if needed. Keep these
 lines short too. A sample list:
 * Item 1
 * Item 2
 * Item 3
 Another paragraph in the commit description. Blah blah blah.


Once you have committed some stuff, you can push these to the repository on github using git push. This works since by default the push command pushes to a remote called origin, and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).


When you want to get the latest changes from the repository on Gitorious, you generally use git pull. However, note that this command does not work when you have local changes. Also, when you have local commits, the pull command will generate a merge commit (and before that you may have to resolve some conflicts).

If you don't want to create merge commits, but would rather stack your local commits on top of any incoming commits, you should use git pull --rebase. This rebases your local commits on top of the incoming ones. You should never do this when you have pushed these commits elsewhere, so only do it when you are sure the commits are only on your machine.

If you have local changes and want to update your checkout, then there are several options:

  • You commit your local changes, and do a pull, optionally with --rebase.
  • Or you use git stash to place your local changes on a "hidden" stash. Then, after pulling, you apply your changes again with git stash apply.
  • Or you create a patch of your local changes that you apply again after the pull. This approach sometimes makes sense, but I would say in general it's the more clumsy way to go. There are git commands that help you with this though.

Resolving conflicts

Rather similar to Subversion. When there are conflicts, a merge or a rebase will add conflict markers into files. Use git status to see which files remain in conflict and use git add on files to mark them as resolved. When you did a merge and you have resolved all conflicts, you commit. When you were doing a rebase of several commits, you do git rebase --continue instead.

Patch making

Git has an easy way to send patches to other people to review and commit for you. After you have made a commit, git format-patch will make a patch out of it. The patch includes your author information the commit message you gave, and all the changes to be done. The recipient can just git am [patch file] to apply the commit. After it has been pushed, you'll need to remove the patch from your local repository, git reset --hard HEAD^ will do that. If you don't do that, you'll get a conflict when your patch is pulled from the central repository.

Good to know

Git has several useful commands to figure out the current state of your repository, your files and what recently changed. Below is a non-exhaustive list of commands that are useful to know:

  • git branch: Without any parameters, this command lists your local branches, and indicates which branch you're currently on.
  • git whatchanged: This shows a list of all commits on the current branch similar to git log, but with a list of the files that have been touched in each commit as well.
  • git status: This shows all kind of things about your current checkout: which files changed, untracked (unknown) files, added or removed files, files that have conflicts (during merge), etc. It also shows the status of your index, which is what git will commit once you do git commit. If you're new to git I would recommend to wait a bit with learning how to use the index, but not to avoid it forever.

There are also additional applications that help you with using git:

  • gitk: A simple but effective tool that visualizes the history and some of your current state. Run with --all to have it show all branches, otherwise it will just show stuff relevant to your current branch.
  • tig: A textual interface, rather similar to an email reader.
  • git gui: A gui tool like gitk which helps you prepare and perform your commits. Also makes it easier to understand the index concept.
  • Giggle
  • qgit
  • git-cola :
  • SmartGit :'

git on Windows

When using git on Windows you might use msysgit. If you notice that some files seem to have changed after doing a fresh clone, you may want to disable core.autocrlf using git config core.autocrlf false. However, this is not recommended for contributors since the setting makes sure you don't commit Windows style newlines into the repository. When encountering this problem it is usually best to consult other developers about the affected files. GitHub works uses the same tools as Git.


git on MacOS X

MacOSX is an unix system, BSD derived. Git works there mostly as on Linux systems. Go to the official download site: and choose the OS X link, download and install. You also may prefer and add a graphical user interface later (links are on the same pages). Xcode and X11 are required if you want to install from sources. French users may also like:

  • GitHub for Mac github

has it's own application that you can find at Among others, it has a very nice feature to be able to pull and push in one operation.


You may like this very nice interactive memo: git-cheatsheet by Andrew Patterson from NDP software.

  • Branch
  • Clone
  • Commit
  • Fork
  • Mainline
  • Master
  • Merge
  • Origin
  • Patch
  • Pull
  • Push
  • Stash
  • Tree