# gEDA/gaf's Source Control Management

gEDA uses git for source code management. git is a distributed version control system, where every user has his or her own full copy of the revision history.

- Official git website
- git documentation online
- git Wikipedia page

The web interface to the gEDA git repository is at http://git.gpleda.org/.

## Installing git & related tools

The core git tools are of course required for using the repository, and the documentation is always useful. However, other tools are often helpful for working with git:

- gitk, a visual history repository browser
- Stacked Git, for working with patchsets

Make sure that you install at least version 1.5.x of git if you are planning on pushing changes to the central git repository.

Debian-based

    apt-get install git-core git-doc gitk stgit

you may also want:

    apt-get install git-email git-completion

Note, as of 2007/06/25, Debian stable (etch) and Debian testing (lenny) have git version 1.4.x. Debian unstable (sid) has 1.5.2.2.

Fedora Linux

    yum install git stgit

## Learning to use git

The toplevel documentation for git can be found at:

Official git docs

The user’s manual for git can be found at:

git user manual

A current tutorial can be found at:

git core tutorial

Other nice tutorials/webpages:

Git Guide
git Crash Courses

Keep in mind that some of these tutorials are a little dated and may not cover current git syntax.

## Accessing the repository anonymously

To clone the gaf.git repository (or any repository hosted at git.gpleda.org) using anonymous git access:

    git clone git://git.gpleda.org/gaf.git

or

    git clone git://git.gpleda.org/pcb.git

For different repositories hosted at git.gpleda.org, just substitute the last part of the above URL.

## Accessing the repository with write permission

For developer git access, you should contact Ales Hvezda to get an SSH public key installed and an account; having done so, the git URL to push to is:

    git clone ssh://<username>@git.gpleda.org/home/git/gaf.git

or

    git clone ssh://<username>@git.gpleda.org/home/git/pcb.git

If you have ssh access you will also need to edit your ~/.ssh/config file (create it if it doesn’t exist) and put the following text into it:

    Host git.gpleda.org
    Port 5022

## Accessing the repository using anonymous CVS

Finally, it is possible to access the repository using CVS, as there is a git-cvsserver running. This is read-only access.

     export CVSROOT=:pserver:anonymous@git.gpleda.org/home/git/gaf.git
     cvs co master

You can only checkout exported heads (for example: master).

## Making and committing changes

### Setting up user information

You should make sure that your username & e-mail address are set in your git configuration file.

    $ git config --global user.name "Your Name Comes Here"
    $ git config --global user.email you@yourdomain.example.com

### Committing patches from other contributors

If you apply a patch from someone else (e.g. from a SourceForge patch record) there are a few things to consider. Git stores two different names and e-mail addresses for a given commit: the “author” of the patch, and the “committer” of the patch, so these details must be set correctly when making the commit.

First of all, check a few things:

- You have the latest version of the patch.
- The author of the patch is happy for it to be committed (and wasn’t still working on it)
- That the you’re happy with the patch, and taking responsibility for committing those changes.

For simplicity, start from an unmodified up-to date tree (git status shows no changes).

Apply the patch as usual (as an example):

    $ patch -p1 < example_changes.patch

You can also use the git apply command:

    $ git apply example_changes.patch

If the patch needs any minor editing before it is committed (eg. white-space changes), please inform the author this was done. They may have other work based on their patch and will want to know if there were changes to the applied version.

Note: This is easy to miss accidentally if your editor introduces tabs. Please avoid letting it do so!

For every file changed, added or removed, you need to inform git before it will commit the changes. To see the modified files, run:

    $ git status

For speed, the command:

    $ git add -u

will update all files which git tracks, including any files which were deleted.

For adding any new files the patch introduced, use the command

    $ git add new_file.c

Note: git add also takes wild-cards.

Commit the patch, making sure that the Author’s name and e-mail address are specified:

    $ git commit --author "Author's Name Comes Here <author@example.com>"

As an alternative, you can set the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables before issuing the normal commit command

### Writing good commit message

The commit message format is as follows: a *strictly* one-line summary of the patch, followed by a blank line, followed by a long description. If you can fit the whole description of the patch on one line, that’s fine; don’t bother with the long description.

The one-line summary is used for generating e-mail subject lines, and for the gitk & gitweb log displays. Having a good one-line summary is really useful, because it means those tools can be used to quickly find a commit of interest.

Do not put a list of files changed into commit messages. This information can be trivially obtained using the git tools.

Example:

    Added new GedaList class derived from GObject

    This abstracts a GList with API for write access. Its main use is in list
    change notification, as it emits a "changed" g_signal when modified.
    Read only access to the underlying GList is provided by an accessor,
    currenly implemented as a macro.

### Push is Destructive

Warning: pushing changes to the remote repository is destructive

Unlike CVS, it is not the committing of changes which changes the master repository, but pushing changes using git-push. You should always double- (or triple-) check that the commits you are about to push are actually meant for the main repository.

## How Do I ... ?

For a more information please checkout the Git Guide.

### ... get a copy of gEDA/gaf git repository?

For anonymous read-only access:

    $ git clone git://git.gpleda.org/gaf

For developers with read/write access:

    $ git clone git://git.gpleda.org/home/git/gaf.git

### ... keep my local copy current?

For those who are are not merging changes back into the central git repository you can run:

    $ git pull

However, for those of you who are going to be pushing your changes back into the central git repository, using git pull will clutter up the history with merge messages (“Merge branch ‘master’”). To avoid this you should run:

    $ git fetch
    $ git rebase origin

### ... commit my changes to the local git repository?

    $ git commit -a

This command will find all changed files that git knows about (added with git-add) and prompt you for a commit message. Be sure to follow the above commit message convention if you plan on pushing your changes to the central repository.

If you want to commit files in the current directory or want to explicitly commit only certain files, do not specify the -a flag and/or specify the individual filenames on the command line like:

    $ git commit filename1 filename2

### ... undo any uncommitted local changes?

    $ git checkout -f

Note this will discard any changes to any files that are being tracked by git.

If you want to just discard edits in a single file, just run:

    $ git checkout path/to/file/to/discard

If you want to discard all edits from the current directory and downward recursively, just run:

    $ git checkout .

### ... fix/change my last commit?

    $ Edit whatever files
    $ git commit --amend filename1..filenameN

This will pickup any changes you made and recommit them again with the previous commit message.

### ... track a branch?

    $ git checkout --track -b <local name> origin/<remote name>

This will create a branch with the <local name> which tracks the <remote name>‘d branch.

### ... create a branch (starting at a tag)?

Run the following commands (using the stable-1.4 branch as an example):

     $ git branch stable-1.4 1.4.0-20080127
     $ git checkout stable-1.4
     <make changes>
     $ git commit -a

To publish this branch in the central repository (requires write access to the central repository):

     $ git push origin stable-1.4

### ... fetch a development branch from other people?

Beside the http://git.gpleda.org/ repository we have a mirror of that repository at http://repo.or.cz/w/geda-gaf.git. Some of the developers have forks of that repository with new feature branches.

If you like to test one of the feature branches you have to fetch it from their repository. The easiest way to get a branch is to use the fetch command.

      $ git fetch repository_url remote_branchname:local_branchname

Examples: Getting the cairo_experiment branch from Peter C. would look like this:

      $ git fetch git://repo.or.cz/geda-gaf/pcjc2.git cairo_experiment:peters_cairo_experiment

Now you can switch to the local copy of the branch peters_cairo_experiment and play with it.

### ... format a patch to send to the developers?

The simplest possible way:

    $ git diff > name_of_patchfile

A more complicated way:

    $ git add -i           # select files to be committed
    $ git status           # check you're committing what you think you're committing
    $ git commit           # create a commit
    $ git format-patch -1  # create a patch file based on that commit

This will output a filename which contains the patch. Be sure to look at the documentation for format-patch for more information. This file can be e-mailed to developers who have write access and can be applied using git apply.

### ... recover from a really messed up local repository?

First off, do not push any repository that you think is somehow messed up. Ask one of the experienced git people first.

Second, the command that will really save your bacon is git-reflog. Using it works something like this:

     $ git reflog
     086908e... HEAD@{0}: cherry-pick: Last minute updates to the READMEs for all pro
     2a79a23... HEAD@{1}: checkout: moving to master
     2a79a23... HEAD@{2}: checkout: moving to master
     ...
     $ git reset --hard HEAD@{1}

The last command (git reset –hard …) will rollback all your changes to the “checkout: moving to master”. Remember: don’t panic! Most things are fixable when using git.