» Git-SVN: Using Git to Interact with Subversion Repositories FND’s Blag: Just Another Personal Wobsite

Git-SVN: Using Git to Interact with Subversion Repositories

Published in May 24th, 2008

Posted by FND

Lately I have been reading about and toying with Git a lot — and I’m truly fascinated! (In fact, I’m even using it to track the progress of this very posting.)
However, I’m not primarily interested in the distributed part. More important, to me, is the fact that Git gives me a private revision history (local commits). That way I can commit frequently without having to worry about publishing my changes prematurely.^[1]

Since for TiddlyWiki we’re using Subversion, I’ve started looking into Git’s SVN module. With this I can use Git locally while still interacting with the public Subversion repository.

The following guide is to serve as a quick introduction to Git-SVN, hopefully making it easy for others (e.g. fellow Osmosoftonians) to get started.
Note that I’m an enthusiastic command-line user, which is why this guide does not cover any GUIs. Also, I’m far from being a Git expert at this point, so feel free to suggest improvements!

Initial Setup

check out Subversion repository:^[2]^[3]
```
git svn clone -T[trunk_subdir] -t[tags_subdir] -b[branches_subdir] [URL]
```
(e.g. git svn clone -TTrunk -tTags -bBranches http://svn.tiddlywiki.org)
N.B.: For TiddlyWiki, it might not be desirable to convert the Trunk, Tags and Branches directories to metadata, as this might interfere with Cook.
create branch for work in progress (WIP):
```
git checkout -b [branch]
```

Working with Git

modify files on WIP branch, creating (and amending) local commits:^[4]
```
git add [files]
git commit -m "[message]"
git commit --amend
```
switch to master branch:
```
git checkout master
```
grab changes from WIP branch:^[5]
```
git merge --squash [branch]
```

commit changes and push to Subversion:^[6]

git commit -a -m "[message]"
git svn dcommit

switch back to WIP branch:^[7]
```
git checkout [branch]
git reset --hard master
```
(if there are additional commits on the branch, git rebase master should be used — which might lead to merge conflicts though)

Useful Commands

git branch (list, create or delete branches)
git diff [-w] [--color-words] (display changes)
git apply (patching)
git status (working tree status)
git log (commit history)^[8]
git reflog (comprehensive history)
git svn rebase (update local repository)
git checkout [files] (revert changes)
git config (user preferences)^[9]
git gui (graphical user interface)
gitk (repository browser)

Thanks to Kerry for getting me started with Git in the first place!

2008-09-30: minor updates (removed hyphens from git svn commands, updated .gitconfig, note on converting metadata on checkout)

2008-11-03: changed final git merge master to git reset --hard master (includes a note on git rebase master, as recommended by Kerry)

The same is true for other DVCS, like Mercurial — though I have only worked with Git so far. [↩]
Cloning an entire Subversion repository can take a while (mostly due to protocol overhead) — an alternative is to grab only the latest revision: git svn init [URL]; git svn fetch -r HEAD. [↩]
Instead of manually specifying directory names for trunk, tags and branches, -s can be used for the standard naming convention “trunk”, “tags” and “branches”. [↩]
Use git commit -a -m "[message]" to automatically add all modified files. [↩]
Squashing means that several local commits can be merged into a single commit. [↩]
dcommit will automatically perform an update (rebase). [↩]
The merge operation is required due to the rewritten commit history on the master. [↩]
git log can be used to display the differences between two branches: git log <a>..<b> — for example: git log origin/master..master (Git repositories), git log remotes/trunk..master (SVN repositories) [↩]

My current .gitconfig file (latest version on GitHub):

[user]
	name = FND
[alias]
	ci = commit
	cia = commit -a
	cim = commit -m
	ciam = commit -a -m
	co = checkout
	diffi = diff -M --color-words
	diffw = diff -M -w
	diffx = diff -M -w --color-words
	merges = merge --squash
[color]
	branch = auto
	diff = auto
	status = auto
[color "branch"]
	current = yellow reverse
	local = yellow
	remote = green
[color "diff"]
	plain = white
	meta = yellow bold
	frag = magenta bold
	old = red bold
	new = green bold
[color "status"]
	header = white
	added = yellow
	changed = green
	untracked = cyan
[svn]
	rmdir = true

[↩]

4 users responded in " Git-SVN: Using Git to Interact with Subversion Repositories "

HeX said, in May 24th, 2008 at 09:37

Nice summary,
I would be careful with the ‘–squash’ option though. Since this means the commit history of the svn repo only contains a (maybe) huge junk of changes within one commit. I think there is probably no harm to let your colleagues who haven’t seen the light yet (i.e. still using svn) to know which discrete steps led to your awesome new piece of code (and in case it wasn’t all that awesome might help them debugging it by following your multiple commits instead of a huge one). But that’s up to you. You even might consider squashing only some of the commits together. The ‘–interactive’ option is a great tool for this.

Perhaps you might also highlight shortly how ‘git-svn dcommit’ works (i.e. first pushes all your commits from your repo up to the svn repo one by one and *then* does a rebase so that the time line of the svn repo and your git repo are in sync).

As for your last step of all the single commits (switching back to your WIP branch) there is really no alternative other than:
a) git-svn rebase
b) git merge master
‘b)’ being probably much faster and can be done locally as no network connection is required

And last but not least…there is a Trac plugin available http://trac-hacks.org/wiki/GitPlugin. So why not switching to GIT completely with dev.tiddlywiki.org (Yes I know the learning curve for new users *seems* to be quite steep and handling of sub-modules is also not the easiest to get your head round)

FND said, in May 24th, 2008 at 10:08

Thanks HeX!

> I would be careful with the ‘–squash’ option though.
> Since this means the commit history of the svn repo only
> contains a (maybe) huge junk of changes within one
> commit.

You do have a point there.
However, I’m actively trying to avoid that my local Git usage results in less frequent (and thus more opaque) commits to the public repo.
IMO, a public commit should form a meaningful and coherent unit — which the individual local commits often don’t. So once I’ve got such a chunk ready, I push it to SVN (see TiddlyWiki timeline).

> You even might consider squashing only some of the
> commits together. The ‘–interactive’ option is a great
> tool for this.

I’ll definitely look into that.

> highlight shortly how ‘git-svn dcommit’ works

You just did — thanks for that! (I didn’t wanna bloat the post with too many details.)

> As for your last step of all the single commits (switching
> back to your WIP branch) there is really no alternative

Good to know I wasn’t completely off.
I’ll change that step to use merge soon (need to try it myself first).

> why not switching to GIT completely with dev.tiddlywiki.org

Apart from the fact that changing an existing (and proven) system is always a hassle, switching to Git would probably scare off a lot of (potential) developers. It’s hard enough getting people to use SVN… (Although for someone who has never used a VCS before, learning Git is probably not any harder than getting used to SVN.)

> there is a Trac plugin available

I’ve heard of that, but haven’t seen it in action yet.

HeX said, in May 24th, 2008 at 12:13

>> why not switching to GIT completely with
> dev.tiddlywiki.org
>
> Apart from the fact that changing an existing (and
> proven) system is always a hassle, switching to Git
> would probably scare off a lot of (potential)
> developers. It’s hard enough getting people to use
> SVN… (Although for someone who has never used a VCS
> before, learning Git is probably not any harder than
> getting used to SVN.)

Yes I wasn’t really serious here as I also experiencing exactly the same “arguments” in my working environment. Once svn 1.5 is out which finally can remember the history of a merged branch (so I was told) it’s probably not all that bad anyway (well there still is the repo size, the network dependency, and the speed…)

Also, I was very much tempted to go for Bazaar (well Ubuntu is using it for launchpad so it should be pretty good) but I couldn’t get used to the workflow that every branch created resides in a separate directory in your workspace and has to stay there if you want to work with that branch.

>> there is a Trac plugin available
>
> I’ve heard of that, but haven’t seen it in action yet.

Have a look at the project page. There are some example pages given that use that plugin.

» Git Basics: Getting Started FND’s Blag: Just Another Personal Wobsite said, in March 28th, 2009 at 10:43

[...] Published in March 28th, 2009 Posted by FND Tags: development, Git, revision control Since my last post on the subject, I’ve become much more familiar and comfortable with [...]

Leave Your Reply Below...

Comment moderation may be active. There is no need to resubmit your comments.

FND’s Blag

Git-SVN: Using Git to Interact with Subversion Repositories

4 users responded in " Git-SVN: Using Git to Interact with Subversion Repositories "

Leave Your Reply Below...

Twitter

Recent Entries

Recent Comments

Meta

Archives

Blogroll