Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

rjbs
  (email not shown publicly)
http://rjbs.manxome.org/
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)
I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Monday July 09, 2007
11:12 AM

making the switch to git

[ #33759 ]

A few months ago, Dieter and I played around a bit with git. He used it more than I did, but we both agreed that it was way cool. It came up again at YAPC, and I gave it another look. It's come a long way in those few months! The need for a friendlier user-oriented command apart from git is basically gone, and the tools for interoperation with other VCS finally exist and seem to work well.

On the way home from YAPC, I converted my personal Subversion repository into a few git repositories. Now I'm looking at the way forward for converting (code (simply))'s repository. (We haven't decided to do this, but I'm very tempted, at present.) We have a fairly common setup, from what I've seen of the Subversion-using world:

./project/{branches,trunk,tags}/content

The git-svnimport command is meant for dealing with projects in repositories that start at the second level, with the trunk (et cetera) forming the root. That's not a big deal, because you can tell git-svnimport to use project/trunk as the trunk directory, and so on. The problem is that for quite a few projects, the name changed once during the course of history. So, what is now Sub-Exporter was once just exporter. I'm not sure how to get a full history import while switching from one large Subversion repo to many small git repositories. I think that perhaps I can import the entire repository and then somehow slice it up from there, then drop the "massive" git repository in favor of the sliced up pieces. I'm not sure how to go about doing that, yet.

At any rate, I'll have to figure out how to do it before we make any decisions. It sure would be nice, though.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

making the switch to git 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What are some specific things you like about 'git' ? I especially interested if you could compare it to darcs, but comparing it to svn would be interesting, too.
    • I have only used both git and darcs for fairly simple use cases, and in my limited and unqualified opinion, they're very close to each other in terms of what they can do. git struck me as faster and as easier to install. It doesn't yet have the interactive commit (record) that darcs has, but this is apparently in the works.

      My third-hand knowledge tells me that the repository structure of git is incredibly simple, which is why there have been other implementation of it. Someone linked to a page called "Wh
      --
      rjbs
      • Thanks for the response.

        In terms of "installing darcs", I usually just drop a binary into /usr/local/bin/. It has a few minor dependencies, like "libcurl". However, it's been stable enough lately that a recent pre-packaged binary for a given platform is probably fine.

        I seem to recall there was a darcs-subproject to have it be able to be a client for a git repository, but I quit following that since I don't need that feature.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.