[MPlayer-dev-eng] git-svn

[Clément Bœsch]

On Sat, Jan 22, 2011 at 08:38:04PM +0100, Diego Biurrun wrote:
> 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.
> 

Here we go, yet another beginner howto :)

> So, everybody, please install git and run
> 
>   git svn clone svn://svn.mplayerhq.hu/mplayer
> 

What about using the mirror at git.mplayerhq.hu?

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

You might also be interested in aliases like:

  % grep alias -A 7 ~/.gitconfig
  [alias]
  	st = status
  	ci = commit
  	br = branch
  	co = checkout
  	df = diff
  	lg = log -p

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

You should mention a bit the branches. Imagine you just clone the
repository:

  Server:             [1]--[2]--[3]
* lo (master branch): [1]--[2]--[3]

First thing to is to create a dev branch for the thing you'd like to fix or
feature you'd like to create; so from the master branch, you do for example:

  git checkout -b vobsub-fix

So you get:

  Server:                 [1]--[2]--[3]
  lo (master branch):     [1]--[2]--[3]
* lo (vobsub-fix branch): [1]--[2]--[3]

Well, time to hack in your branch. You basically make various commit, while in
the same time on the server new commits are pushed.

  Server:                 [1]--[2]--[3]--[4]--[5]
  lo (master branch):     [1]--[2]--[3]
* lo (vobsub-fix branch): [1]--[2]--[3]--[X]--[Y]--[Z]

Alright, you have your fix, what comes next? Well, the first thing we thought
about is a merge, so you get something like this:

                          [1]--[2]--[3]--[4]--[5]-----[MERGE]
                                     `---[X]--[Y]--[Z]--/

Which can be pretty ugly (and not easy to revert thing, or do more rebase).
Let's do something clean. So first we go in the master branch (git checkout
master):

  Server:                 [1]--[2]--[3]--[4]--[5]
* lo (master branch):     [1]--[2]--[3]
  lo (vobsub-fix branch): [1]--[2]--[3]--[X]--[Y]--[Z]

And update it (git pull):

  Server:                 [1]--[2]--[3]--[4]--[5]
* lo (master branch):     [1]--[2]--[3]--[4]--[5]
  lo (vobsub-fix branch): [1]--[2]--[3]--[X]--[Y]--[Z]

Let's go back to the vobsub-fix branch, and rebase the [X]--[Y]--[Z] commit
onto master. This means those 3 patches get applied on top of master:

  git co vobsub-fix
  git rebase master

And if everything went fine, you get:

  Server:                 [1]--[2]--[3]--[4]--[5]
  lo (master branch):     [1]--[2]--[3]--[4]--[5]
* lo (vobsub-fix branch): [1]--[2]--[3]--[4]--[5]--[X]--[Y]--[Z]

You can now send your tree patches to mplayer-dev-eng (with git-send-mail, or
with send the patches generated with git format-patch HEAD~3)

When everything is fixed and is ready to push:

  git checkout master
  git merge vobsub-fix
  git push
  git branch -d vobsub-fix

I don't know how this kind of manipulation work with git-svn though :)

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

IMO, we should start committing at least a .gitignore, and apply the patch from
divVerent for the version.sh…

-- 
Clément B.