Table of Contents
How to work with git repositories
Required packages:
- git-core
- git-core-slug (suggested, >= 0.12)
- rpm-build-tools >= 4.5-3
Prepare working dirs
Move existing (CVS-based) ~/rpm
directory:
mv ~/rpm ~/rpm.cvs
Prepare new directory:
builder --init-rpm-dir
Building package
For now one needs to use local ~/rpm/packages/builder
:
cd ~/rpm/packages/ ./builder -v -bp python-msgpack
Set your configuration
Your identity (NOTE: This sets globally):
git config --global user.name "Your Name" git config --global user.email <email>
One can do it per package too in each ./.git/config
file:
[user] email = <your_login>@pld-linux.org name = Your Name
but as for now one needs to set it in each package fetched.
If you have an RW access to PLD Linux repositories please use
your PLD Linux alias <your_login>@pld-linux.org>
as email.
If you have github account and wish github mirror being updated with your credentials (referencing github resources, closing pull request), you may wish to setup SSH Agent forwarding so that github sync is performed with your credentials. You need to have same key or github key in ssh agent. Such ~/.ssh/config
will enable SSH agent forwarding when pushing:
- ~/.ssh/config
Host git.pld-linux.org ForwardAgent yes
Additionally some useful git config:
Enable colored diffs (reference)
git config --global color.ui auto
Add git st
and some other aliases (reference)
git config --global alias.st status git config --global alias.ci commit git config --global alias.up pull --rebase git config --global alias.ssh '!ssh git@git.pld-linux.org'
when pushing in git-core >= 1.8.0 (reference)
git config --global push.default simple
Download package
git clone git://git.pld-linux.org/packages/<package> cd <package>
or
slug.py clone <package> cd ~/rpm/packages/<package>
If you have RW access you can also use ssh access:
git clone git@git.pld-linux.org:packages/<package> cd <package>
In directory you will find local copy of main branch in the upstream
repository. It is usually called master
.
Remark:
In git repositories there are two kind of branches: local ones on which
you work, and remote ones, which tracks changes in upstream
repository. The remote branches live in a different namespaces: remotes. The
default remote is called origin
, so the main remote branch is
usually called origin/master
. Clone, besides other things, creates a local
master
branch that tracks remote origin/master branch.
Commit your changes
First you put your changes in a staging area - the index:
git add file
Then you can produce a commit from contents of index:
git commit
You can also skip the staging area by:
git commit -a
It will commit the changes in every tracked file. If you want to add new file
to the repository you still need to add it explicitly with git add
Remarks:
- Commit in git are atomic so put related changes to multiple files into one commit.
- Write nice commit logs.
Push your changes upstream
Most git operations change only your local repository. If you want to update upstream repository you need to push your changes. However if you have cloned the packages using git directly from git daemon, you need first to set URL for pushing (for obvious reason anonymous pushes using git daemon are not supported):
git remote set-url --add --push origin git@git.pld-linux.org:packages/<package>
If you have cloned the repository using slug.py too, the URL for pushing has been already set by slug.py.
Then you can push your changes:
git push origin master
where master is a name of branch you want to push. If you are not certain whether you will push to the right branch you can first try:
git push --dry-run origin master
Modify commit messages
commit messages can be annotated with git notes
feature.
Read more on mailing list: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2012-July/022786.html
Update your repository
git fetch origin
It will update all your remote-tracking branches. It will not change your local branches or working directory. For this you need to commit your changes to your local branch and then explicitly merge changes from remote branch to it. For example:
git merge origin/master
Alternatively to get a more clean history you can rebase your changes on top of remote branch:
git rebase origin/master
Work on some other branch
First you need to create your local branch. If you want to follow the remote branch foo, the simplest way is to:
git checkout <branch>
It will create local branch <branch> which tracks remote branch origin/<branch>.
List all your local branches:
git branch
All remote branches:
git branch -r
All branches (local and remote)
git branch -a
Pushing big files
You shouldn't (can't) push bigger files than 2MiB. Big files, including patches, should be stored in distfiles.
If the file is accessible by url, just add # SourceX-md5:
or # PatchX-md5:
comment to the spec, and the file itself does not need to be added to git index. remove/revert if you already did. If the file is generated locally, you need to upload it to distfiles before pushing.
There's exception if you can't do that (is too hard to do due local modifications), you can add the patch filename into .bigfiles
file. See pld-devel-en post.
After you found you pushed and was rejected by big file restriction, you can fix it like this (assuming it was only single commit):
echo 7.3.640 > .bigfiles git add .bigfiles git commit --amend git push origin master
Graphical repository browser
Sometimes it is useful to see a graphical representation of all branches. It can obtained with:
gitk --all
You can limit the set of commits shown by by gitk. For example to present only two branches:
gitk branch1 branch2
Create new package
slug.py init <package>
To be able to use builder
script or push your changes upstream
you have to create local branch in newly created repository:
cd <package-repo> touch <specfile> git add <specfile> git commit -m 'Init commit'
slug.py init and git add can be replaced with:
./builder -a <specfile>
and then:
git push -u origin master
Use template specs for new packages
Often it is good idea to start working over new spec starting from spec templates available:
git clone git://git.pld-linux.org/projects/template-specs.git
Rename package
Assume we want lowercase python-Flask:
$ ssh git@git.pld-linux.org move python-Flask python-flask
try build to download new version:
nice builder -v python-flask
rename spec file:
$ cd python-flask/ $ git mv python-Flask.spec python-flask.spec
Update spec with name change and commit changes.
More information on git
RW access ussing ssh public keys
Listing your keys
To list currently available keys:
ssh git@git.pld-linux.org sskm list
If you use different keypair (.ssh/id_rsa_pld_linux
in my case) to connect specify it:
ssh -i ~/.ssh/id_rsa_pld_linux git@git.pld-linux.org sskm list
One can even make keypair change transperent by adding ~/.ssh/config
:
Host git.pld-linux.org IdentityFile ~/.ssh/id_rsa_pld_linux
Adding new key
Generate pair ( id_rsa_matkor_pld_linux_app4
and id_rsa_matkor_pld_linux_app4.pub
in my case)
ssh-keygen -f ~/.ssh/id_rsa_matkor_pld_linux_app4
@app4
needs to be unique. use sskm list
to see what names are used
Add it (as key app4
in my case):
cat ~/.ssh/id_rsa_matkor_pld_linux_app4.pub | ssh git@git.pld-linux.org sskm add @app4
Confirm (using -i of new key ):
ssh -i ~/.ssh/id_rsa_matkor_pld_linux_app4 git@git.pld-linux.org sskm confirm-add @app4