[MPlayer-dev-eng] git-svn

[Diego Biurrun]

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
and thoughts.

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
revisions.

Then you can start programming as usual.

  git status
  git diff

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
often enough.

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.
Try running

  git diff
  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
backend, run

 git svn dcommit --rmdir

I found the following tutorial helpful:

http://git.or.cz/course/svn.html

More links, amendments, comments and whatnot welcome.

Diego