Questions for Git usersTweet
Thu, Feb 24, 2011 12:36 PM
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?
Matt Graham Says:
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.
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?
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.
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.
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.