I have been using git more and more. I use it in all of my CPAN modules. I’m using git to the point where I expect everything else (that is, svn) to be just as powerful and fast. Unfortunately that just is not the case, and I’m still stuck with it for all but one project at work.. For example, the other day I wanted to find the last commit that my coworker made. With git it would just be git log –author wes -1. I couldn’t seem to figure out a way to do it with svn. Maybe I’m just dumb? Add on to that the fact that git log is mega fast but if you do svn log You Have Made a Mistake. Also the colors! Who doesn’t like the fact that git has colors out of the box?

To sum up the previous paragraph: I need to learn to use git-svn. Lets get started:

First off, you need to make a users file. At my company that’s pretty easy since there are like, 12 people who have commit access to svn. This is what it looks like:

Put it in a file named “users” in the current directory. All this does is substitute the svn names (on the left) for the git names (on the right.) Next up, check out your repository:

This assumes that /foo/bar has subdirs /trunk, /branches, and /tags. If yours is different you’ll want to do something like the following:

Of course you might need to do some tweaking there.

Now, we have three other svn:externals repositories in our repo. This is the most ghetto part of all of this, and it’s probably just because I haven’t done the appropriate research. Again, if you know better, just tell me. (Normally with git you’d do this with a submodule, but we aren’t going to do that because we want to directly check the “submodule” out from svn so we can commit back easily. If you don’t know what a submodule is, ignore this )

This will check out the svnexternal1 repo to a folder called $to_name. If you need to check it out to a separate subdir either cd into that dir or change $to_name.

You don’t want to check that into svn because your coworkers already have an svn:externals for that. Normally this would be done with .gitignore, but we won’t use that because your coworkers don’t want a .gitignore file in their repository. Instead you’ll use .git/info/exclude, which is the same thing but not inside of the repo. Just put $to_name on a single line in that file and it won’t show up in your available changes when you need to commit.

Speaking of commiting, how do you commit? Normally your workflow should be the way it is with git. You commit often and when you are ready for a feature to go to the team you push it out. I usually rebase and clean up commits before I push, but that’s up to you. The main difference is that you don’t do git push … Instead you’ll do

git svn rebase actually checks out the new changes from svn and puts them in your repository before the changes you’ve already committed. If there are conflicts you’ll have to deal with those of course, but otherwise it will just pull in the changes and then use dcommit to submit new changes. You should not have any uncheckedin changes when you do this (it will complain if you do) because dcommit actually does a different kind of rebase after checking in changes. It changes your commits to include the svn id so that the git commits match up with the svn commits.

In general that’s all there is to it. At some point I’d like to do a post about how I use git rebase fairly often in my workflow, but this I think is a lot more important. Oh and here are some cool new git features I learned today. Enjoy

Woohoo! git!

I am so happy to announce that DBIx::Class has migrated to git!

If people latch on well, this should benefit is in a number of ways. The first thing is that most people should appreciate is the ability to check in to source control without needing to commit to the remote repository. Not only does this make things way faster, it also means that you can work sanely offline. A lot of people did this before with SVK, but SVK is slow and a hassle (I think) to install and setup.

Another thing that this should help is our history. I don’t mean to point out a specific person, I did this all the time with svn (it’s just the nature of the beast,) but take a look at some of these commit messages. The SVK merge messages are pretty obnoxious, but that’s not what I’m referring to. The ones that bother me are the: “Oops,” “Typo,” “Thinko,” etc. With git those can be cleanly squashed into another commit. In fact, I would recommend cleaning up your history before you push every time. This is how I do that:

That will rebase your current branch (all of it) onto master, and give you an editor that will let you fix commit messages, merge commits, and more. If people do not do this I fully intend to do it myself before I merge a branch in, if I do. And that brings me to the next point which we shall discuss.

Workflow

We toyed with the idea of setting up git such that everyone would just use github or gitorious or whatever and ribasushi and I would be in charge of merging remote branches into the DBIC master, but mst veto’d the idea in favor of a more communal approach. Basically the workflow we will use looks like the following:

1. Get a commitbit (liberal policy)
2. Clone the repo (dbsrgits@git.shadowcat.co.uk:DBIx-Class.git)
3. Make a topic branch based on what you are doing, do work on it, whatever
4. Push branch to repo
5. Ask a fellow DBIC’er to review the branch, that includes me, ribasushi, Caelum, and really anyone else with a commitbit
6. If the reviewer thinks everything is sane, the reviewer will merge the branch in; to be a bit more clear, you should not merge your own branch into master, that is the reviewer’s job
7. Delete your branch locally and remotely after everything is merged in, and work on other stuff!

A note about merges, don’t merge master into your branch. It makes for yucky history. Instead, rebase your branch onto master. Currently the thought is that anything except for master can be rebased. Of course if you and another dev are working in the branch you might want to keep that to a minimum, but at the very least you should be rebasing to squash silly commits before you push, and then when you do the final merge into master you should rebase first, so that history remains sane. Of course, the best time to rebase to fix silly history is before you push, and the best time to rebase to make it so that you are fastforwarding master is right before the final merge, so try to only do that then.

At some point I plan on writing a DBIx::Class::Manual::Contributing in the spirit of Moose::Manual::Contributing, but ours will be significantly more lax. In the meantime, just swing by #dbix-class, get your commitbit, and help out!

This is almost entirely so that I remember how to do this. A big thanks for arcanez for showing me this in the first place.

The Problem

In the Perl community, numerous important git repositories are hosted at shadowcat, but of course if you went to that url you would not be able to see all the work that I have spent on each of those projects. I like the fact that github has a nice concise view of my work.

The Solution

The following is an example of a section from my .git/config in my DBIx-Class-DeploymentHandler:

This lets you push to origin, github, or all. I tend to only pull from origin and push to all. Hopefully this can at least be a reference for people

I just posted a workflow for Git on the Rakudo Wiki. Hopefully it works well and helps people use Git and work on Rakudo. Enjoy!