<SYSTEM_TASK:>
Given the following text description, write Python code to implement the functionality described below step by step
<END_TASK>
<USER_TASK:>
Description:
 Revision control software
J.R. Johansson (jrjohansson at gmail.com)
The latest version of this IPython notebook lecture is available at http
Step1:  In any software development, one of the most important tools are revision control software (RCS).
They are used in virtually all software development and in all environments, by everyone and everywhere (no kidding!)
RCS can used on almost any digital content, so it is not only restricted to software development, and is also very useful for manuscript files, figures, data and notebooks!
There are two main purposes of RCS systems
Step2:  If we want to fork or clone an existing repository, we can use the command git clone repository
Step3:  Git clone can take a URL to a public repository, like above, or a path to a local directory
Step4:  We can also clone private repositories over secure protocols such as SSH
Step5:  In this case, only the current ipython notebook has been added. It is listed as an untracked file, and is therefore not in the repository yet.
Adding files and committing changes
To add a new file to the repository, we first create the file and then use the git add filename command
Step6:  After having added the file README, the command git status list it as an untracked file.
Step7:  Now that it has been added, it is listed as a new file that has not yet been commited to the repository.
Step8:  After committing the change to the repository from the local working directory, git status again reports that working directory is clean.
Commiting changes
When files that is tracked by GIT are changed, they are listed as modified by git status
Step9:  Again, we can commit such changes to the repository using the git commit -m "message" command.
Step10:  Removing files
To remove file that has been added to the repository, use git rm filename, which works similar to git add filename
Step11:  Add it
Step12:  Remove it again
Step13:  Commit logs
The messages that are added to the commit command are supposed to give a short (often one-line) description of the changes/additions/deletions in the commit. If the -m "message" is omitted when invoking the git commit message an editor will be opened for you to type a commit message (for example useful when a longer commit message is requried). 
We can look at the revision log by using the command git log
Step14:  In the commit log, each revision is shown with a timestampe, a unique has tag that, and author information and the commit message.
Diffs
All commits results in a changeset, which has a "diff" describing the changes to the file associated with it. We can use git diff so see what has changed in a file
Step15:  That looks quite cryptic but is a standard form for describing changes in files. We can use other tools, like graphical user interfaces or web based systems to get a more easily understandable diff.
In github (a web-based GIT repository hosting service) it can look like this
Step16:  Discard changes in the working directory
To discard a change (revert to the latest version in the repository) we can use the checkout command like this
Step17:  Checking out old revisions
If we want to get the code for a specific revision, we can use "git checkout" and giving it the hash code for the revision we are interested as argument
Step18:  Now the content of all the files like in the revision with the hash code listed above (first revision)
Step19:  We can move back to "the latest" (master) with the command
Step20:  Tagging and branching
Tags
Tags are named revisions. They are useful for marking particular revisions for later references. For example, we can tag our code with the tag "paper-1-final" when when simulations for "paper-1" are finished and the paper submitted. Then we can always retreive the exactly the code used for that paper even if we continue to work on and develop the code for future projects and papers.
Step21:  To retreive the code in the state corresponding to a particular tag, we can use the git checkout tagname command
Step22:  We can list the existing branches like this
Step23:  And we can switch between branches using checkout
Step24:  Make a change in the new branch.
Step25:  We can merge an existing branch and all its changesets into another branch (for example the master branch) like this
Step26:  We can delete the branch expr1 now that it has been merged into the master
Step27:  pulling and pushing changesets between repositories
If the respository has been cloned from another repository, for example on github.com, it automatically remembers the address of the parant repository (called origin)
Step28:  pull
We can retrieve updates from the origin repository by "pulling" changesets from "origin" to our repository
Step29:  We can register addresses to many different repositories, and pull in different changesets from different sources, but the default source is the origin from where the repository was first cloned (and the work origin could have been omitted from the line above).
push
After making changes to our local repository, we can push changes to a remote repository using git push. Again, the default target repository is origin, so we can do
Step30:  Hosted repositories
Github.com is a git repository hosting site that is very popular with both open source projects (for which it is free) and private repositories (for which a subscription might be needed).
With a hosted repository it easy to collaborate with colleagues on the same code base, and you get a graphical user interface where you can browse the code and look at commit logs, track issues etc. 
Some good hosted repositories are
Github 
Step31:  Graphical user interfaces
There are also a number of graphical users interfaces for GIT. The available options vary a little bit from platform to platform
<ASSISTANT_TASK:>
Python Code:
from IPython.display import Image
Explanation: Revision control software
J.R. Johansson (jrjohansson at gmail.com)
The latest version of this IPython notebook lecture is available at http://github.com/jrjohansson/scientific-python-lectures.
The other notebooks in this lecture series are indexed at http://jrjohansson.github.io.
End of explanation
# create a new git repository called gitdemo:
!git init gitdemo
Explanation: In any software development, one of the most important tools are revision control software (RCS).
They are used in virtually all software development and in all environments, by everyone and everywhere (no kidding!)
RCS can used on almost any digital content, so it is not only restricted to software development, and is also very useful for manuscript files, figures, data and notebooks!
There are two main purposes of RCS systems:
Keep track of changes in the source code.
Allow reverting back to an older revision if something goes wrong.
Work on several "branches" of the software concurrently.
Tags revisions to keep track of which version of the software that was used for what (for example, "release-1.0", "paper-A-final", ...)
Make it possible for serveral people to collaboratively work on the same code base simultaneously.
Allow many authors to make changes to the code.
Clearly communicating and visualizing changes in the code base to everyone involved.
Basic principles and terminology for RCS systems
In an RCS, the source code or digital content is stored in a repository. 
The repository does not only contain the latest version of all files, but the complete history of all changes to the files since they were added to the repository. 
A user can checkout the repository, and obtain a local working copy of the files. All changes are made to the files in the local working directory, where files can be added, removed and updated. 
When a task has been completed, the changes to the local files are commited (saved to the repository).
If someone else has been making changes to the same files, a conflict can occur. In many cases conflicts can be resolved automatically by the system, but in some cases we might manually have to merge different changes together.
It is often useful to create a new branch in a repository, or a fork or clone of an entire repository, when we doing larger experimental development. The main branch in a repository is called often master or trunk. When work on a branch or fork is completed, it can be merged in to the master branch/repository.
With distributed RCSs such as GIT or Mercurial, we can pull and push changesets between different repositories. For example, between a local copy of there repository to a central online reposistory (for example on a community repository host site like github.com).
Some good RCS software
GIT (git) : http://git-scm.com/
Mercurial (hg) : http://mercurial.selenic.com/
In the rest of this lecture we will look at git, although hg is just as good and work in almost exactly the same way.
Installing git
On Linux:
$ sudo apt-get install git
On Mac (with macports):
$ sudo port install git
The first time you start to use git, you'll need to configure your author information:
$ git config --global user.name 'Robert Johansson'
$ git config --global user.email robert@riken.jp
Creating and cloning a repository
To create a brand new empty repository, we can use the command git init repository-name:
End of explanation
!git clone https://github.com/qutip/qutip
Explanation: If we want to fork or clone an existing repository, we can use the command git clone repository:
End of explanation
!git clone gitdemo gitdemo2
Explanation: Git clone can take a URL to a public repository, like above, or a path to a local directory:
End of explanation
!git status
Explanation: We can also clone private repositories over secure protocols such as SSH:
$ git clone ssh://myserver.com/myrepository
Status
Using the command git status we get a summary of the current status of the working directory. It shows if we have modified, added or removed files.
End of explanation
%%file README
A file with information about the gitdemo repository.
!git status
Explanation: In this case, only the current ipython notebook has been added. It is listed as an untracked file, and is therefore not in the repository yet.
Adding files and committing changes
To add a new file to the repository, we first create the file and then use the git add filename command:
End of explanation
!git add README
!git status
Explanation: After having added the file README, the command git status list it as an untracked file.
End of explanation
!git commit -m "Added a README file" README
!git add Lecture-7-Revision-Control-Software.ipynb
!git commit -m "added notebook file" Lecture-7-Revision-Control-Software.ipynb
!git status 
Explanation: Now that it has been added, it is listed as a new file that has not yet been commited to the repository.
End of explanation
%%file README
A file with information about the gitdemo repository.
A new line.
!git status
Explanation: After committing the change to the repository from the local working directory, git status again reports that working directory is clean.
Commiting changes
When files that is tracked by GIT are changed, they are listed as modified by git status:
End of explanation
!git commit -m "added one more line in README" README
!git status
Explanation: Again, we can commit such changes to the repository using the git commit -m "message" command.
End of explanation
%%file tmpfile
A short-lived file.
Explanation: Removing files
To remove file that has been added to the repository, use git rm filename, which works similar to git add filename:
End of explanation
!git add tmpfile
!git commit -m "adding file tmpfile" tmpfile 
Explanation: Add it:
End of explanation
!git rm tmpfile
!git commit -m "remove file tmpfile" tmpfile 
Explanation: Remove it again:
End of explanation
!git log
Explanation: Commit logs
The messages that are added to the commit command are supposed to give a short (often one-line) description of the changes/additions/deletions in the commit. If the -m "message" is omitted when invoking the git commit message an editor will be opened for you to type a commit message (for example useful when a longer commit message is requried). 
We can look at the revision log by using the command git log:
End of explanation
%%file README
A file with information about the gitdemo repository.
README files usually contains installation instructions, and information about how to get started using the software (for example).
!git diff README
Explanation: In the commit log, each revision is shown with a timestampe, a unique has tag that, and author information and the commit message.
Diffs
All commits results in a changeset, which has a "diff" describing the changes to the file associated with it. We can use git diff so see what has changed in a file:
End of explanation
Image(filename='images/github-diff.png')
Explanation: That looks quite cryptic but is a standard form for describing changes in files. We can use other tools, like graphical user interfaces or web based systems to get a more easily understandable diff.
In github (a web-based GIT repository hosting service) it can look like this:
End of explanation
!git checkout -- README
!git status
Explanation: Discard changes in the working directory
To discard a change (revert to the latest version in the repository) we can use the checkout command like this:
End of explanation
!git log
!git checkout 1f26ad648a791e266fbb951ef5c49b8d990e6461
Explanation: Checking out old revisions
If we want to get the code for a specific revision, we can use "git checkout" and giving it the hash code for the revision we are interested as argument:
End of explanation
!cat README
Explanation: Now the content of all the files like in the revision with the hash code listed above (first revision)
End of explanation
!git checkout master 
!cat README
!git status
Explanation: We can move back to "the latest" (master) with the command:
End of explanation
!git log
!git tag -a demotag1 -m "Code used for this and that purpuse" 
!git tag -l 
!git show demotag1
Explanation: Tagging and branching
Tags
Tags are named revisions. They are useful for marking particular revisions for later references. For example, we can tag our code with the tag "paper-1-final" when when simulations for "paper-1" are finished and the paper submitted. Then we can always retreive the exactly the code used for that paper even if we continue to work on and develop the code for future projects and papers.
End of explanation
!git branch expr1 
Explanation: To retreive the code in the state corresponding to a particular tag, we can use the git checkout tagname command:
$ git checkout demotag1
Branches
With branches we can create diverging code bases in the same repository. They are for example useful for experimental development that requires a lot of code changes that could break the functionality in the master branch. Once the development of a branch has reached a stable state it can always be merged back into the trunk. Branching-development-merging is a good development strategy when serveral people are involved in working on the same code base. But even in single author repositories it can often be useful to always keep the master branch in a working state, and always branch/fork before implementing a new feature, and later merge it back into the main trunk.
In GIT, we can create a new branch like this:
End of explanation
!git branch
Explanation: We can list the existing branches like this:
End of explanation
!git checkout expr1
Explanation: And we can switch between branches using checkout:
End of explanation
%%file README
A file with information about the gitdemo repository.
README files usually contains installation instructions, and information about how to get started using the software (for example).
Experimental addition.
!git commit -m "added a line in expr1 branch" README
!git branch
!git checkout master
!git branch
Explanation: Make a change in the new branch.
End of explanation
!git checkout master
!git merge expr1
!git branch 
Explanation: We can merge an existing branch and all its changesets into another branch (for example the master branch) like this:
First change to the target branch:
End of explanation
!git branch -d expr1
!git branch
!cat README
Explanation: We can delete the branch expr1 now that it has been merged into the master:
End of explanation
!git remote
!git remote show origin
Explanation: pulling and pushing changesets between repositories
If the respository has been cloned from another repository, for example on github.com, it automatically remembers the address of the parant repository (called origin):
End of explanation
!git pull origin
Explanation: pull
We can retrieve updates from the origin repository by "pulling" changesets from "origin" to our repository:
End of explanation
!git status
!git add Lecture-7-Revision-Control-Software.ipynb
!git commit -m "added lecture notebook about RCS" Lecture-7-Revision-Control-Software.ipynb
!git push
Explanation: We can register addresses to many different repositories, and pull in different changesets from different sources, but the default source is the origin from where the repository was first cloned (and the work origin could have been omitted from the line above).
push
After making changes to our local repository, we can push changes to a remote repository using git push. Again, the default target repository is origin, so we can do:
End of explanation
Image(filename='images/github-project-page.png')
Explanation: Hosted repositories
Github.com is a git repository hosting site that is very popular with both open source projects (for which it is free) and private repositories (for which a subscription might be needed).
With a hosted repository it easy to collaborate with colleagues on the same code base, and you get a graphical user interface where you can browse the code and look at commit logs, track issues etc. 
Some good hosted repositories are
Github : http://www.github.com
Bitbucket: http://www.bitbucket.org
End of explanation
Image(filename='images/gitk.png')
Explanation: Graphical user interfaces
There are also a number of graphical users interfaces for GIT. The available options vary a little bit from platform to platform:
http://git-scm.com/downloads/guis
End of explanation
<END_TASK>