svn for git-addicted or git-svn gotchas and WTFs – Part 2

Part 1

Hi folks.

Let’s continue our git-svn adventures. In the previous blogpost we’ve managed to fetch the whole svn repo. Let’s discuss some pitfalls.

Local branches

git checkout svn/branch1 -b branch1

this will create a local branch and keeps track of svn version of it.

Main commands to keep yourself updated

git svn fetch # analogue for git fetch
git svn rebase # analogue for git pull --rebae
git svn dcommit # analogue for git push

svn tags

For whatever reasons git-svn gets svn tags not as git tags, but as git branches. I found a lot of articles where they explain how to convert those branches into a vanilla git tags. But from my understanding this makes sense only for one-time-import scenario where you just want to convert your svn repo into git so you won’t keep svn repo anymore. It is not my case so I decided to keep svn “tags” as they are: refs/remotes/svn/tags/v1/v1.0

Atomic commits

The first thing I did after I got my git repo, I took a task and solved it using zillions of micro-commits as I used to. The task took me around 40 commits. And then I wanted to “push” it to the svn repository. ‘push’ in git terms = ‘dcommit’ in git-svn terms.

git svn rebase
git svn dcommit

And guess what? Every single commit was pushing for ~50 seconds. So in total to push all 40 commits it took me ~33 minutes. That’s just unacceptable! I was very frustrated. The whole point of the idea had been compromised.

I decided to change the plan and push only one commit per task. So I still develop with zillions of commits and push them into a parallel git repo, but then I squash those commits and dcommit them into svn repo.

I tried a few approaches.

git checkout -b issue-12345
# make zillion commits
git checkout branch1
git svn rebase
git merge issue-12345 --squash
git commit
gis svn dcommit

This creates one commit for the new feature. I didn’t like the default message produced. It, for example, listed the merged commits in a reverse order. I’ve manually edited it to something like

#12345 New Feature

- Commit 1 Message
- Commit 1 Message
...
- Commit zillion Message

I found this idea is not charming very soon. I have to keep issue-12345 forever if I want to see its commits in a more granular level. Moreover, there is no an obvious relation between squashed merge commit and the original branch.

So then I’ve come to another approach will I like more now. Moreover it looks like I am going to change my habits and use this approach not only for git-svn repos but with a vanilla git repos as well.

The idea is very simple actually. Same as before but keep plain merge without –squash

git checkout -b issue-12345
# make zillion commits
git checkout branch1
git svn rebase
git merge issue-12345 --no-ff -m "#12345 Some bug fix description" 
git svn dcommit

So this creates a commit which looks good from a svn point of view but has a full history in your git.

You don’t even need to keep issue-12345 branch anymore

git branch -D issue-12345

because you can always get a list of these merged commits via

git log myhash^1..myhash^2 # here myhash is a hash for the created merge commit

To be continued…

Part 3

Advertisements

About mnaoumov

Senior .NET Developer in Readify
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

One Response to svn for git-addicted or git-svn gotchas and WTFs – Part 2

  1. Pingback: svn for git-addicted or git-svn gotchas and WTFs – Part 3 | mnaoumov.NET

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s