diego at biurrun.de
Sat Jan 22 20:38:04 CET 2011
I'd like to encourage everybody to switch to git-svn in order to
familiarize oneself with git usage. I've been using it at work myself
and am slowly starting to fall in love with git. I'm not going to deny
that there is a learning curve because there is one and if you are deeply
familiar with Subversion or previously CVS, like myself, then there are
some reflexes to unlearn and some retraining to do.
I'd like to use this thread to share experiences, tip and tricks, HOWTOs
So, everybody, please install git and run
git svn clone svn://svn.mplayerhq.hu/mplayer
which will pull the complete MPlayer repository to your computer while
using up less space than a Subversion checkout. This operation will
take a while, Subversion is not terribly efficient at pulling out old
Then you can start programming as usual.
will do almost the same as the svn equivalents, but if you run
git config --global color.ui true
you will get some fancy coloring as added value.
git log -p
shows you the diffs along with the log messages, which comes in handy
Start hacking and at some point commit your changes.
git commit -a
git commit -a <list of files>
will do what you will expect, but you can try running
git add -p
before and cherrypick individual changes for committing them separately.
git diff --cached
to see what has been staged for commit and what hasn't. With git you
should switch to a "commit early and commit often" workflow. Since you
can edit history and amend your mistakes easily, this pays off greatly.
After a while you will have a bunch of (local) commits lying around in
your repository. Maybe some of them will have issues that you would
like to fix. The next command to try is
git rebase -i git-svn
play around with reordering commits, fixing them, squashing fixup commits
into their parents, rewording commit messages and whatnot.
To get your local repository in sync with the central one on mphq, what
Subversion would call "updating", run
git svn rebase
This will pull in all changes from the central repository and apply all
your local changes on top of it.
When you are happy with the result of your work and think the time has
come to push changes out to the world at large, the command
git svn dcommit
will push all your local commits to the central repository on mphq. It's
good to run
git svn dcommit --dry-run
first to avoid shooting yourself in the foot. Needless to say, I'm
speaking from experience here.
If you just want to push some, but not all, of your changes, use the rebase
command from above to edit the history of your local repo so that the changes
you want to push come first and then run
git svn dcommit --dry-run <hash_of_last_commit_you_want_to_push>
Yes, I'm directly suggesting to use a dry run first, dunno why ;-)
Note that git cannot handle empty directories. While I consider this a
shortcoming, git people generally don't. Oh well, no point in trolling
here... It's a point to keep in mind though because it can cause real,
if rare, issues when interoperating with Subversion.
If you move some files around and leave behind empty directories, you
cannot remove the directories in git directly. You can remove them in
the file system, but git will not record the changes like Subversion
would. To avoid orphaned empty directories in the Subversion repository
git svn dcommit --rmdir
I found the following tutorial helpful:
More links, amendments, comments and whatnot welcome.
More information about the MPlayer-dev-eng