Latest revision as of 12:32, 1 June 2024

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.

Amarok/Development/Git contains the most up-to-date information on Amarok related git topics. KDE Git page also provides more details.

Basic Development

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

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.

git remote add jeff git://git.kde.org/clones/amarok.git/mitchell/pudaction.git
git remote update
git branch -a
git branch jeff-pud jeff/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

git remote add adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

git remote update downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

git branch -a this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

git branch this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

git checkout is how you switch between branches.

Recommended reading  =

The Git Parable Background information that will help you understand git and distributed revision control systems in general
Git to SVN crash course 5 minute introduction to git for experienced SVN users
Shipping Quality Code with Git Guide to cleanup before a push
Git for Computer Scientists Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.
Linus Torvalds on Git Why git? answered by the man that started it.
Git Ready! Learn git one commit at a time
Git Community Book An online book covering git from the basics to some advanced features
Git Magic Covers some concepts and common usage patterns
Zack Rusin's git cheat sheet
Git cheat sheet Yet another git cheat sheet
git by example git command reference and explanation
Git Quick Reference Yet another reference of the most used git commands

Todo for this doc

creating feature branches
history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.

@@ Line 1: / Line 1: @@
-= Getting started with git  =
-== Recommended reading  ==
+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. <br>
-[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable:] ''Background information that will help you understand git and distributed revision control systems in general''<br> [http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
+[https://community.kde.org/Amarok/Development/Git Amarok/Development/Git] contains the most up-to-date information on Amarok related git topics. [https://community.kde.org/Infrastructure/Git KDE Git page] also provides more details.
-== Getting started ==
+=== Basic Development  ===
-===gitorious.org===
+% of the time this is all that is needed:
-* Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and now Amarok.
+ git pull --rebase
-* On your user page, (that's at http://gitorious.org/~your_nick) click on "Manage SSH keys" and add your SSH key.
+ #hack, compile, build. It works!
-* Again from the user page, click on "Manage aliases" and add any email addresses you've ever used in KDE SVN. This way any commits you've made in the past are tracked back to you. If your gitorious email address is the only one you ever used, then this step isn't needed.
+ git status #to check if you want to commit all the modified files
-* Request one of the kde-developers admins to add you to the group (the same rules apply as KDE SVN account requests). This will give you push rights to Amarok. Lydia, Ian and Jeff are all admins.
+ git commit -a
+ git log
+ git push
-===Setup Amarok Clone===
+''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 [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ 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''.
-Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.
+''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 clone git@gitorious.org:amarok/amarok.git
+''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.
-This will create a directory 'amarok'. cd into that and start developing!
+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.
-So what you will do 90% of the time:
+''git push'' pushes all the local commits to the central repo.
-  git pull #update to latest code
-  #edit code, build, it works!
+= Follow remote feature branch =
-  git status #to check if you want to commit all the modified files
+With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.
-  git commit -a #the -a option commits all modified files. use git add to select them individualy
- git push
+Remember that you can't push to git:// URL's when picking what URL to use.
+ git remote add jeff git://git.kde.org/clones/amarok.git/mitchell/pudaction.git
+  git remote update
+  git branch -a
+ git branch jeff-pud jeff/pudaction-removal
+  git checkout jeff-pud
+ #and later you want to switch back to the mainline
+  git checkout master
+''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.
+''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.
-== Getting started for SVN experts  ==
+''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.
-== Getting started for Novices  ==
+''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.
-== Alternatives for users  ==
+''git checkout'' is how you switch between branches.
-- gitorious tarballs - svn snapshots
+ Recommended reading  =
-= Rules for using Gitorious  =
+*[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable] ''Background information that will help you understand git and distributed revision control systems in general''
+*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
+*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
+*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
+*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
+*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''
+*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
+*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
+*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
+*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
+*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
+*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''
-#Never, ever create a branch in our mainline repo. Ever. You can do it locally, but do *not* push it up.
+= Todo for this doc  =
-#Clone the repo and work on that. Add mainline as a remote branch in your local copy of your cloned repo. This will allow you to easily merge back and forth.
-#Pushing branches to your own clone of the mainline repo is fine, however, if you are doing bugfixing or feature branches, use *ONE BRANCH PER FEATURE/BUGFIX*. Gitorious will hopefully improve, but right now it has a downfall in that you can only merge from the start of a branch up to a selected end-point; you can't cherry-pick start and stop points. So if you work on feature A and merge it, then feature B, and want to merge in feature B, you'll have to merge from the start of the branch. So for now at least, just use one branch per feature/bugfix.
-For members of the kde-developers group on gitorious only rule 1 is relevant. Outside contributers need to comply with 2 &amp; 3 to be able to do a request pull.
+*creating feature branches
+*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.