How to commit your code

Get ready to commit/provide your code

There are several options to provide us your code:


Attach patches to issues or send them via mail to .

Pull requests on github

Get an account on and fork ET: Legacy on github. Do your changes/patch and simply send us a pull request.

You’ll find more information on the following page Using Pull Requests.

Full repository access

If you want to contribute to this project regularly, simple visit our IRC channel #etlegacy on Freenode and let us know. We are always open to new contributors.

Don’t worry if you have never used Git before, it is easier than you think.

Configure git to deal with lines ending

Refer to Dealing with line endings to configure git for your platform.

On *nix systems

$ git config --global core.autocrlf input

On Windows

$ git config --global core.autocrlf true

Before you do 'git commit’

Unless you are about to commit a big change in the code use git pull --rebase to update your local repo. In that way there won’t be an unnecessary 'merge’ commit when you do git push.

To maintain a consistent coding style and prevent ugly commit diffs each developer should use uncrustify which reformats the code to a standard defined in source:uncrustify.cfg.

There are slight changes to how uncrustify formats code in between uncrustify software versions,
so we all have to use the same git revision of uncrustify to achieve a consistent source code format.
Current used uncrustify version is f91f1aa05b1f0f935fccebe50def5136a052f805.

Example usage single file:

uncrustify --no-backup -c uncrustify.cfg src/folder/file.c

git pre-commit hook:

Git can execute scripts before doing the actual commit. The attached pre-commit script can be saved as .git/hooks/pre-commit and will check all modified files if they can be uncrustified.
If there are crustified files, it will issue a warning and abort the commit.

Reformat the whole source tree (best practise):

On *nix systems

Download this bash script into the top source code directory.

chmod +x
./ --changed

Alternatively, write your own script such as:

for FILE in $(find src/ -type f -not -name "unzip.c" -name "*.c" \
-or -name "*.cpp" -not -name "g_etbot_interface.cpp" -or -name "*.h" \
-or \( -name "sha*" -prune \) -or \( -name "Omnibot" -prune \)); \
do uncrustify -c uncrustify.cfg  --no-backup ${FILE}; done

On Windows

@echo off
set current=%cd%
FOR /R .\src %%G IN (*.h *.c) DO call:UNCRUSTFILE %%G

set pathstr=%~1
if not x%pathstr:unzip.c=%==x%pathstr% goto:eof
if not x%pathstr:g_etbot_interface.cpp=%==x%pathstr% goto:eof
if not x%pathstr:sha-1=%==x%pathstr% goto:eof
if not x%pathstr:Omnibot=%==x%pathstr% goto:eof
uncrustify --no-backup -c %current%\uncrustify.cfg %~1

We reformat only our own code, so any 3rd party code is excluded. Put the above lines into a batch/sh script and run before each commit.

Pulling existing code

Before pushing, pulling code should be done, and ideally with rebasing:

$ git pull --rebase

Merging code

Patches from other developers should be merged automatically using Github’s pull requests. If that is not possible, make sure to add --author "First Last <>" flag. Only if you are using a small part of other developer’s code or the developer does not have a Github account, add "patch by ..." to the commit message.

How to write a commit message

Example commit title:

client: changed xyz, fixes #111

Commit category

The first word in a commit message defines its category in our automatically generated changelog.

Main categories:
  • client - committed code affects only the client part
  • server - committed code affects only the server part
  • mod - committed code affects only the mod code
    • ui
    • cgame
    • game
  • general - committed code affects both
  • misc - committed code is non-specific, e.g. code clean ups, documentation, ...

Referencing commits

The last part of a commit message consists of a keyword and a number linking the commit to our bugtracker.

Possible keywords:
  • Referencing (the commit is related to this issue, but doesn’t fix it)
    • refs
    • references
    • IssueID
  • Fixing
    • fixes
    • closes
Fixing keywords fixes and closes will automatically close the issue in the bugtracker.

Release Tag

For release tag, the following formats are used:
  • Release
    • v%i.%i
    • v2.71
  • Patch level
    • v%i.%i.%i
    • v2.71.1

pre-commit - git pre-commit hook to check for crustified code. (654 Bytes) deki, 19.02.2013 19:15