Questions for Git users

Thu, Feb 24, 2011 01:36 PM
So, we have been using Subversion for a long time. We are very comfortable with it. We know how it works. Even when things go sideways, we have people here that understand it and can set things straight again. But, we do find some things lacking. I had an SVN conflict today where the diff showed the problem to be that I was replacing nothing with something. That was a conflict. Sigh. Also, it is getting slower and slower as time passes. Committing or updating my code base can take long enough that I start checking email and forget I was committing something. So, we are thinking about a switch. I use GitHub for some of my OSS software I have released. I like GitHub a lot. I find the Git command line tool a little confusing (commit -a seems silly for example). But, I figure I can get over that. I am going to end up wrapping it up in our merge and deploy tools anyway. But, I have some questions for people that use Git on a daily basis. I have searched around and there is either more than one answer or no answers to these things.

How big is your repository?

We have 1,610 directories and 10,215 files in our code library. How does Git deal with repositories that size?

What are you using for a Git server?

From what I can tell, there is no server component to Git. I think I understand that you can use a shared Git use and allow ssh keys to access it that way? Or there are some other 3rd party projects that act as a Git server. We currently use Apache+SVN which lets us A) Use our LDAP server and B) control access to parts of the repository using Apache configuration. It looks like we would lose the LDAP for sure but maybe something like Gitolite would allow us to do some auth/acl stuff. Maybe we could dump our LDAP data on a schedule to something it can read.

What is your commit, push, deploy procedure?

This is really aimed at the guys doing continuous deployment in a web application with Git. Our current methodology is that each developer has a branch. They commit to their branch. When a set of commits is ready for release, they push it to trunk. In a staging environment, the changeset in trunk is merged with the production branch. That branch is then rolled to the servers. We like having the 3 layers. It lets us review changes in one place (trunk) for large commits. Meaning there can be 10 commits in a developer's branch, but when all the changes are merged into trunk (using one SVN merge of course) you get one nice neat commit in the trunk branch that can easily be evaluated. It also lets users collaborate easily by committing changes to trunk that others may need. Other users can just merge back from trunk to get the changes. From what I have read or heard people talking about, this seems to fly in the face of how Git works. Or, at least what Git is good at. Also, I think the way Git works, 10 commits in a branch would merge as 10 commits in trunk. So, we would lose the unification of a lot of little changes getting merged into one change. Some of our developers will use their branch to commit things in progress and not at a finished point. So, by the time they are done, we will have 10+ commits for one task. Any input here?

What are you using for visualization?

We use Trac. We love and hate Trac. Its good enough. I know Redmine supports Git natively and I know there is a Trac Hack for making Trac support it. Anything else? Any comments on Redmine?

Any tips for importing from Subversion?

I tried importing our Subversion repos into Git using svn2git. It got hung up on some circular branch reference or something. The error message was confusing. So, I guess if we do migrate, we will be starting with little to no history. Perhaps we just import our current production branch and start from there. Any tips?
3 comments
Gravatar for Matt Graham

Matt Graham Says:

Repo Size:
Git doesn't allow checking out pieces of your repo, you get the whole thing or nothing. Because of this, it's likely you'll want to break your monolithic svn repo into a few separate git repos. More than number of files or directories, git struggles with large, compressed binary files. You want to minimize those when you migrate. If you need big binary files, consider putting them in a submodule so they don't have to be dealt with all the time.

Server:
You still want a central server, just like github is for your OSS software. Check out gitosis http://bit.ly/hU3znx for user privileges. I've used it to easily manage 60+ developers.

Can you use a service like github, unfuddle or codebasehq?

Process:
Don't change what you do now. Git allows all kinds of workflows, it doesn't mean you use the most exotic. Switching to git is enough of a change w/o destabilizing your work flow. Once you've switched, improvements may reveal themselves, but iterate on what you have now, don't start all over.

Visualization:
This only becomes clear once you've gotten used to them, but git grep and git log are way better tools for finding code than a web interface. There are lots of interfaces out there, and most of them are good enough for sending links to people.

Import:
Try git svn clone. It will probably take forever, but work around your branching problem. You can use a command line regex to filter out what you don't want. Consider importing just trunk to still get most of your history without branching or merging issues.

Gravatar for tim

tim Says:

git commit -a is a shortcut for two commands.
git add [files or chunks of files] to the staging index &
git commit for writing the staged changes to history.

git was built to manage the linux kernel. the kernel is larger than your project. Your project in git will be smaller and faster than svn.

git push/deploy/etc
you will have to change your workflow some, but git rebase --interactive allows you to squash together single commits into a single commit. you can also tag points in history in your master repository for identifying important spots in the timeline.

Redmine is great.

Add A Comment

Your Name:


Your Email:


Your URL:


Your Comment: