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.
Re:specifics?
rjbs on 2007-07-09T21:37:06
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 "Why Repository Formats Matter," but I don't have the link, and finding it over my cell modem would be a drag.
I haven't yet done a lot of branching and merging, but from what I have watched and read, it is far, far easier to merge than in Subversion. It's trivial to branch in Subversion, but merging is still a pain. (Of course, this is better than in CVS, where merging is death itself.)
The distributed nature of git is really keen, and I'm looking forward to being more involved with projects that use git, just to be forced to get a beter grip on using it.
I'll be perfectly honest: I picked git because it was easy to install, provided a fairly simple migration path for my simple repo (without Taylor, thankfully), and my first few experiments went well. I spent a long time waffling between darcs and git, and git is just what I ended up deciding to use. I think this will end up being a good decision based on the architecture of the git repo and its porcelain/plumbing tools. I think those will lead it to become more successful than darcs, but that's just armchair prognostication.
Jeez, though... git is fast.Re:specifics?
markjugg on 2007-07-10T18:35:41
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.Repository Formats Matter
Ron Savage on 2007-07-10T00:54:47
http://keithp.com/blog/Repository_Formats_Matter.htmlRe:Repository Formats Matter
rjbs on 2007-07-10T01:44:57
I love the lazyweb.