Mesa uses git as its source code management system.
The master git repository is hosted on freedesktop.org.
You may access the repository either as an anonymous user (read-only) or as a developer (read/write).
You may also browse the main Mesa git repository and the Mesa demos and tests git repository.
To get the Mesa sources anonymously (read-only):
git clone git://anongit.freedesktop.org/git/mesa/mesa
git pull origin
git clone git://anongit.freedesktop.org/git/mesa/demos
Mesa developers need to first have an account on freedesktop.org. To get an account, please ask Brian or the other Mesa developers for permission. Then, if there are no objections, follow this procedure.
Once your account is established:
git clone git+ssh://username@git.freedesktop.org/git/mesa/mesaReplace username with your actual login name.
git pull origin
git clone git+ssh://username@git.freedesktop.org/git/mesa/demos
If you're using git on Windows you'll want to enable automatic CR/LF conversion in your local copy of the repository:
git config --global core.autocrlf true
This will cause git to convert all text files to CR+LF on checkout, and to LF on commit.
Unix users don't need to set this option.
At any given time, there may be several active branches in Mesa's repository. Generally, the trunk contains the latest development (unstable) code while a branch has the latest stable code.
The command git-branch
will list all available branches.
Questions about branch status/activity should be posted to the mesa3d-dev mailing list.
If you try to do a pull by just saying git pull
and git complains that you have not specified a
branch, try:
git config branch.master.remote origin git config branch.master.merge master
Otherwise, you have to say git pull origin master
each time you do a pull.
If you are an experienced git user working on substancial modifications, you are probably working on a separate branch and would rebase your branch prior to merging with master. But for small changes to the master branch itself, you also need to use the rebase feature in order to avoid an unnecessary and distracting branch in master.
If it has been awhile since you've done the initial clone, try
git pull
to get the latest files before you start working.
Make your changes and use
git add <files to commit> git commit
to get your changes ready to push back into the fd.o repository.
It is possible (and likely) that someone has changed master since you did your last pull. Even if your changes do not conflict with their changes, git will make a fast-forward merge branch, branching from the point in time where you did your last pull and merging it to a point after the other changes.
To avoid this,
git pull --rebase git push
If you are familiar with CVS or similar system, this is similar to doing a
cvs update
in order to update your source tree to
the current repository state, instead of the time you did the last update.
(CVS doesn't work like git in this respect, but this is easiest way
to explain it.)
In any case, your repository now looks like you made your changes after
all the other changes.
If the rebase resulted in conflicts or changes that could affect the proper operation of your changes, you'll need to investigate those before doing the push.
If you want the rebase action to be the default action, then
git config branch.master.rebase true git config --global branch.autosetuprebase=always
See Understanding Git Conceptually for a fairly clear explanation about all of this.