µ C l i b c
About Documentation Obtain Development Links

Anonymous Git Access

We allow anonymous (read-only) Git access to everyone. To grab a copy of the latest version of uClibc using anonymous git access: 
git clone git://uclibc.org/uClibc.git

If you are not already familiar with using Git, here are some useful links:

Once you've checked out a copy of the source tree, you can update your source tree at any time so it is in sync with the latest and greatest by entering your uClibc directory and running the command: 

git pull
Because you've only been granted anonymous access to the tree, you won't be able to push any changes.

Git Config

You should make sure to have your git environment properly set up before trying to do any sort of patches/commits. Here is a sample:
$ git config --global user.name "Your Full Name"
$ git config --global user.email "your.real.email@address.com"

Contributing

So you've made some changes and you would like to contribute them back. Great! The way we handle this is via our Mailing Lists. Just sign up to the dev mailing list, describe the changes (what/why/how/etc...), and include your patch.

Since we are using git, that means the repository you check out is a standalone repo and can have all the normal commands run on it. That means you should commit your changes to it and then create/e-mail the resulting patch. Unlike centralized source control systems, the "commit" step is broken up into two steps: (1) commit to the repository (in this case, your local repo) and (2) push to the central repository (only official developers can do this).

So the normal code flow will look something like:

  1. Make changes to the repo (create/modify/delete files)
  2. Use `git add` to queue your changes for committing
  3. Use `git commit` to commit changes to the repository
  4. Use `git format-patch` to create a patch of your changes
  5. Use `git send-email` to send that patch to the mailing list

Things to keep in mind when submitting your patches:

  • Too much information is better than not enough!
  • Split patches into separate logical changes rather than one giant mess
  • Include a "Signed-off-by" line (use the '-s' option with `git commit`)
  • The proper format for the commit changelog is different with git compared to svn (see below)
  • Use `git format-patch` and `git send-email` to sanely create and send e-mails; if you don't, you have to:
    • If you post patches inline, please turn off word wrapping and other such e-mail mangling "features"
    • If you attach patches, please make sure you flag them as "automatic display"
    • Do not compress patches (the list currently has 100k limit -- if your patch is bigger, more likely you're doing it wrong)

To make the e-mail process simpler, you should set the mailing list in your git repo accordingly (run this in the checked out repo): 

$ git config --add sendemail.to uclibc@uclibc.org

When writing a changelog for your commit, you should use the proper changelog format to ensure nice workflows with other git commands. This format is fairly strict and unlike centralized scm's you might be familiar with such as svn or cvs. Note that the Signed-off-by tag can easily be added by using the '-s' option when running `git commit`. 

the first line is a short one-liner summary

After a blank line, you should use complete sentences with lines properly
wrapped at e-mail lengths.  You should also include relevant information
such as output from tools showing errors.

After all of your explanatory text, there should be another blank line and
then the relevant tags (Signed-off-by/CC/etc...).

Signed-off-by: Your Full Name <your.real.email@address.com>
Once you have a properly written changelog, use `git format-patch` to turn a commit into an e-mail. You can then edit the patch to add additional info after the triple dash which comes after the commit tags: 
---
the triple dash above is used to mark the end of the changelog and the start
of any additional comments that should not be included in the changelog ...
that may include things like changes in the proposed patch itself, or random
questions for people

New Developers

To obtain commit access, you will need to demonstrate you are serious by submitting a few good patches first. This is accomplished via our Mailing Lists. So you've contributed quite a bit and you're still here? Let's move on then!

There's the fun logistic issues to work out first, so here's the new developer check list:

  • Your preferred username for committing to the server
  • Your preferred e-mail address for contact
  • Your public ssh key (should be ssh version 2 key with 2048 bits (the default) or, preferably, more)
If you do not have a public ssh key, then you can easily generate one. Simply use the command: 
ssh-keygen -b 4096
This will output the files id_rsa (your private key -- do not give this to anyone!) and id_rsa.pub (your public key -- give this to me). By default, both files will be placed in your home directory in the .ssh subdir.

While not required, you should also create an account on our Bug Tracker. When you have, simply e-mail me the username on the tracker so that you can have your account settings changed from the default "reporter" to "developer" (this allows you to make changes to all bug reports).

Committing

Once you are setup with an account, you will need to use your account to checkout a copy of uClibc: 
git clone ssh://username@uclibc.org/git/uClibc.git
It goes without saying you must change username to your own username... For the adventurous, you could set the username in your ~/.ssh/config file as well of course.

You can then enter the newly checked out uClibc directory, make changes, check your changes, diff your changes, revert your changes, and and commit your changes using commands such as: 

git log
git diff
git status
git checkout
git reset
git add
git commit
git push

For additional detail on how to use Git, please see the top of this page for helpful links.

Other Services

Now that you have an account on the server, there's a few things you are given access to for free.
  • shell: simply ssh to username@uclibc.org
  • e-mail: username@uclibc.org (you can forward this by using ~/.forward)
  • web: https://uClibc.org/~username/ (this is your ~/public_html/ directory)
  • git: https://git.uClibc.org/~username/git/ (this is your ~/git/ directory)

To use a personal git repo you would do something like this: When using a clone, a bare one is sufficient and please consider using a shallow one (--depth 1 or something low). 

me@busybox ~/git $ mkdir mything1.git
me@busybox ~/git $ cd !$
cd mything1.git
me@busybox ~/git/mything1.git $ git init --bare
Initialized empty Git repository in /home/me/git/mything1.git/
me@busybox ~/git/mything1.git $ touch git-daemon-export-ok
me@busybox ~/git/mything1.git $
Done with the server-side. 
me@client:/tmp$ git clone git+ssh://me@uclibc.org/~/git/mything1.git
Cloning into mything1...
warning: You appear to have cloned an empty repository.
me@client:/tmp$ cd mything1/
me@client:/tmp/mything1$ echo FOO > FOO
me@client:/tmp/mything1$ git add FOO
me@client:/tmp/mything1$ git commit -s -m 'do something' FOO
[master (root-commit) 0c2bd20] do something
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 FOO
me@client:/tmp/mything1$ git push -v --thin origin master
Pushing to git+ssh://me@uclibc.org/~/git/mything1.git
Counting objects: 3, done.
Writing objects: 100% (3/3), 240 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git+ssh://me@uclibc.org/~/git/mything1.git
 * [new branch]      master -> master
me@client:/tmp/mything1$ echo "ANOTHER" >> FOO
me@client:/tmp/mything1$ git commit -s -m 'do something else' FOO
[master 7010bf0] do something else
 1 files changed, 1 insertions(+), 0 deletions(-)
me@client:/tmp/mything1$ git push -v --thin
Pushing to git+ssh://me@uclibc.org/~/git/mything1.git
Counting objects: 5, done.
Writing objects: 100% (3/3), 283 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git+ssh://me@uclibc.org/~/git/mything1.git
   0c2bd20..7010bf0  master -> master
me@client:/tmp/mything1$
Note that using "push origin master" is only required the first time.

Please keep the number of repos as well as their size down. If you need more space, use some other hosting facility. Thanks for your understanding.


If you have any other questions, feel free to post them to the list.
Copyright © 1999-2012 Erik Andersen
Mail all comments, insults, suggestions and bribes to
Bernhard Reutner-Fischer
 This site created with the vi editor This site is kindly hosted by OSL