Contact

If you like a new Web or Desktop
application, update a existing one
or add new modifications. Your at
the right place and hit the
hire me button

Follow

If your intersted you can follow
me on Twitter by clicking here

Web and Apps Building Refernce World Wild Web UNIX Apps AND Tips Programming languages

Git Work Flow

The calice reconstruction software is currently manged with the stupid content tracker (git). It allows to easily mess with different branches of the software and destroy your day-work in one blink.

Checking out the initial versions

Initially the master archive has to be cloned. This is achieved by:
git clone http://polywww.in2p3.fr/~gaycken/Calice/Software/download/calice.git Calice
The whole git archive may be quite fat, since all development branches are cloned. Then You have to switch to the proper branch (Initially the branch is set to master which may not be the desired branch). You can get a list of possible branches with:
git branch
To change to the correct branch, do:
git checkout [branch-name]
Now, You have the whole history in Your directory. To browse the history log, do:
git log
The first thing You should do is to create a branch of Your own to mess with:
git checkout -b [my-branch-name]
This should create and checkout a new branch of the given name. Now, You can start working.

Checking in changes

Git tracks changes to individual files, addition and removal of files. Git also can handle the renaming or moving of files. After You have applied several changes you should check the changes into the git repository. You can get a list of all applied changes recognised by git using:
git status
You may want to modify or create the file .git/info/exclude, and maybe you want to add files .gitignore to each directory. In these files you can inform git about files or file name patterns of files which should not be tracked.
git-update-index [files whose contents was changed]
git-add    [new files]
git-delete [files which were delete]
git-rename [files which were renamed]
After having informed git about all changes which should be grouped together in a single commit, you can commit the changes with:
git commit -m "... [message] ..."
If no message is given the default editor is started. If You are not happy with a commit because you missed some changes or you made a spelling mistake in the message You can undo commits and recommit:
git reset --soft HEAD^
The ^ after HEAD means one version earlier than the current HEAD i.e. the version just before the commit. Now you can inform git about some additional changes . For example:
git-add    [new files]
Now recommit. If You want to remove some changes from the list of changes you want to add to the commit. You have to remove them all and add them again:
git reset HEAD
git-add [new files]
git-update-index [files whose contents was changed]
...
Note: here the argument after reset is HEAD instead of HEAD^ because the group of changes was not commit yet. Thus, HEAD still points to the status after the previous commit, which we don't want to touch.

The changes will only be checked into Your private repository. To push them to the master repository there is the command:

git push origin
If you do not have write access to the master repository you should create patches and sent them by email to someone with write access:
git diff [sha1-before-change] [sha1-after-change] > my.patch
or
git diff HEAD^ HEAD > $USER_[branch_name]_[one_word_explanation].patch

Updating the private repository

From time to time You should synchronise Your repository with the master repository. This is acomplished by:
git pull origin
If there are conflicts, it may become rather tedious to solve them. (Do You have suggestions to improve this section? They are very welcome.)

Checking out versions

To check a specific version out of the repository do:
git checkout -f [tag]/[sha1]/[branch name]
where [tag] is any valid tag found in the directory .git/refs/tags/, [sha1] is the hash of a version, or [branch name] is a valid branch name found in the directory .git/refs/heads/. Note: Before checking out versions you should check in all Your changes into Your local repository to avoid data loss.

If You don't checkout the head of a branch using [branch name] and You do not have a private branch yet, then you should create one and checkout into the new branch:

git checkout -f -b [new branch name] [tag]/[sha1]