This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to to the appropriated devel list. Be sure to follow the thread to ensure that it doesn't get lost.

+

This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to amarok-devel@kde.org -- just be sure to follow the thread to ensure that it doesn't get lost :-)

If you want to use a local clone for working on bug fixes or features, do the following:

If you want to use a local clone for working on bug fixes or features, do the following:

Line 50:

Line 50:

*You can follow the main development branch easily by adding it as remote branch:

*You can follow the main development branch easily by adding it as remote branch:

−

git remote add upstream git://git.kde.org/amarok (for example)

+

git remote add upstream git://git.kde.org/amarok

*Update by pulling from the remote:

*Update by pulling from the remote:

Latest revision as of 23:47, 7 February 2014

Warning

This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the KDE Git hub page for more details.

Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation.

Follow and test the latest development code

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

Patch Contributions

This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to amarok-devel@kde.org -- just be sure to follow the thread to ensure that it doesn't get lost :-)

If you want to use a local clone for working on bug fixes or features, do the following:

Create a branch for each new feature or bug fix you want to work on:

git branch my_feature_branch

Switch to the new branch:

git checkout my_feature_branch

Work, fix that bug or add the feature...

...work on this checkout - follow the normal development workflow...

Commit it to your local checkout:

git commit -a

You can follow the main development branch easily by adding it as remote branch:

Amarok Developers

Account Setup

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://sysadmin.kde.org/tickets/ and provide your logon and your SSH pub key.

Setup Amarok Clone

Once you have a KDE development SSH account, a basic local clone for development work that allows push access can be created by running:

git clone git@git.kde.org:amarok

This will place a clone in the "amarok" subdirectory of the current folder.

If for some reason port 22 will not work for you (such as if you behind a firewall allowing only ports 80 and 443 through) you can use port 443 on git.kde.org by specifying the port in ~/.ssh/config:

Host git.kde.org
Port 443

You can also create your own server-side clone of the Amarok repository and store your changes there. Others can then pull from your repository or add your repository as a remote.

Please note that personal clones are using KDE infrastructure and meant for KDE-relevant work, and as such you cannot change the access policy that allows everyone to read these clones (but you can change who can write to them, as explained below). Please do not create clones to e.g. make changes to customize code for your company. If you want to do this, host your clone on Gitorious.org or GitHub.com instead.

To create a personal clone, run the following command, substituting your KDE username and a reponame of your choice, *without* a trailing ".git":

After that, you will have a fully functioning repository of your own at git://git.kde.org/clones/amarok.git/[username]/[reponame] or git@git.kde.org:clones/amarok.git/[username]/[reponame] for read-only and push URLs, respectively.

You can delete this repository at any time by running the "destroy" command:

ssh git@git.kde.org destroy clones/amarok.git/[username]/[reponame]

Rights Management

When your clone is created, it is setup to allow all KDE developers push access to it. This is in keeping with KDE's everyone-can-write-anywhere philosophy. You are strongly encouraged to keep this default.

However, we understand that at times you may want to ensure that the work you are doing is not modified by anyone else until you are finished, or reach a milestone, or some such thing.

@all is a special groupname that indicates all KDE developers. It is the only special name allowed in the permissions.

To modify them, create a file named anything you like -- I'll use "myperms". In "myperms" enter those that should have RW access by their KDE user account name. The RW statements are cumulative, or can specify multiple user accounts on one line:

RW = hein bcooskley
RW = toma

At the end of this, the total push permissions will be comprised of *you* (the creator of the clone, in my case "mitchell"), hein, bcooskley *and* toma. Note that *you* are the only one that can push and delete new branches and tags; the other contributors only have push access. In other words, you are your own release manager for your clone.

Now, use the "setperms" command to set the permissions, passing in the file you created:

Basic Development

git pull --rebase downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of git pull; git rebase origin/master. See the "1. Rebase" section of Shipping Quality Code for a good explanation of what rebase does.

If you have uncommited changes you can not rebase. Instead you can git stash, do the rebase, and then git stash apply.

git status will tell you what files are modified. If you created a new file, use git add on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

git commit -a will commit all unmodified files. You can use git add and then simply git commit instead if you wish to commit only certain files.

Use git log to review the local unpushed commits. Possibly also useful is git diff origin/master, which will give you a diff between the current checkout and what is in the central repo.

git push pushes all the local commits to the central repo.

Follow remote feature branch

With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.