Scott Hanselman

Hanselminutes Podcast 108 - Exploring Distributed Source Control with Git

April 16, '08 Comments [18] Posted in Podcast
Sponsored By

git-logo My one-hundred-and-eighth podcast is up. In this episode I sit down with Robby, Gary and Andy from Planet Argon, a local Rails shop in Portland, OR, and talk about their experience as they move from Subversion to Git for their source control.

Links from the Show

Subscribe: Subscribe to Hanselminutes Subscribe to my Podcast in iTunes

If you have trouble downloading, or your download is slow, do try the torrent with Āµtorrent or another BitTorrent Downloader.

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is our sponsor for this show.

Check out their UI Suite of controls for ASP.NET. It's very hardcore stuff. One of the things I appreciate about Telerik is their commitment to completeness. For example, they have a page about their Right-to-Left support while some vendors have zero support, or don't bother testing. They also are committed to XHTML compliance and publish their roadmap. It's nice when your controls vendor is very transparent.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

Technorati Tags:

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Wednesday, 16 April 2008 08:45:55 UTC
Great show! I have been wanting to know more about Git for a while. I saw Linus presentation on it a year ago but I did not really get everything.

I hope there is a TortoiseGit in the works, because one of the best things about subversion is how great and effortless TortoiseSVN makes it.
Wednesday, 16 April 2008 11:14:02 UTC
Yay! Good show. Git rocks my world.

I haven't been getting as much of my Hanselman 'fix' lately, after moving from .NET to Ruby, full-time, about 6 months ago (and Windows to Linux over a year ago, after literally a lifetime on Windows).

Dunno how your general audience feels, but I love the non-MS/.NET-specific Hanselminutes episodes to give me an excuse to listen :P

By the way, people are doing all kinds of neat things with git ... for example, TicGit is a super neat ticketing system built right into your git repo! Some people are using repos for their blogs, as a kindof database ... I like using branches for deployment (checkout old branch to rollback) ... some of these things aren't necessarily specific to git, but it's certainly caused a bit of a craze!
Wednesday, 16 April 2008 12:38:09 UTC
Okay, seriously, how is Linus' name pronounced??? I've always heard his name pronounced with a long 'I' sound.

Anyway, I'd be interested in seeing git gain more ground on Windows (like not having to use cygwin).
Wednesday, 16 April 2008 12:44:37 UTC
I really enjoyed this podcast because it introduced me to the concept of distributed source control, something I hadn't thought about before.

However, I'm surprised you didn't talk about the performance and disk space requirements for storing the entire repository's change history on a developer's PC. For example, if I were to start using Git on a large enterprise application with 6 years of revision history, would "get latest" take seconds or minutes? If the codebase itself is nMB, what multiple of n would be required for the Git repository?
Seth Petry-Johnson
Wednesday, 16 April 2008 13:38:14 UTC
David check out You do not need cygwin using this.
Wednesday, 16 April 2008 13:55:27 UTC
David, if you pronounce 'Linus', it's with a long 'I'. But he is finnish, so natively for him, it's with a short 'I'.

Scott, great show, as always. I think the "word from the sponsor"-section really shows you professional touch on everything you do. The first podcast with the commercial-break was a disaster! That Frankling-guy tries to do the trademarked slipstreamed commercial, which is to say the least, despicable.

"So, what's your thought on Git... by the way, how do you create Web 2.0-applications with 1.0-technologies?" Crazy stuff. Like I said, your approach is much better and more professional.

Looking forward to the next show!
Wednesday, 16 April 2008 14:11:34 UTC

I still have yet to hear why merges are so much better and easier in GIT. From what you explained it sounds the same as what you do with subversion? And, with subversion 1.5 adding mergetracking it will even be easier soon including selective revision merging.

Please someone tell me what makes merging so much better in GIT?

Bob Archer
Wednesday, 16 April 2008 14:51:31 UTC
Ahh, Bob. You beat me to it! You're right; Subversion 1.5 will go a long way to fixing the well-known merge hassles, along with the very useful sparse-checkout feature.

One of the guys in the podcast mentioned that GIT has one location where it stores the DB so that your working copy is nice and clean - unlike Subversion where you have .svn (or _svn) directories within *every* working copy directory. Well, that is planned as a future feature of Subversion. I'm sure if enough of us thought it was a problem, we could get it's priority raised.

So the other big thing about GIT seams to be the distributed nature of the repository. Doesn't SVK do that?

I really like Subversion, I think it's great. There is room for improvement though - especially for Windows users. How about integration directly with IIS rather than into Apache? How about a repository-level configuration option for case insensitivity so that '/trunk/myfile.txt' and '/trunk/MyFile.TXT' are the same file? (Not everybody in the world is running UNIX, you know!) Now I know that I've griped about Subversion a little here, but I can't imagine that these particular issues are going to be any different with GIT since it has pretty much the same heritage.

Anyway, Scott. You mentioned that you're getting the Team System guys onto Hanselminutes. How about getting the SVN guys on so they can have right of reply wrt GIT?
Damian Powell
Wednesday, 16 April 2008 17:51:32 UTC
Some very interesting concepts in the GIT model it would be very cool to have full check-in and check-out operations while offline.

One part I am having a very hard time with is the full repository on everyone's machine? How does security work in that world? What about very large code bases? For example our total repository size is well over a tarabyte and I am sure most people do not have that much disk space on their machines.

As always I love learning about new things on hanselminutes.
Chris Patterson
Wednesday, 16 April 2008 20:14:44 UTC
From what I have seen with Git, when you pull down and create a local repostiory you are not pulling back the full history, but just the most recent stuff. I could be wrong though.
Bob Archer
Wednesday, 16 April 2008 22:14:18 UTC
@Bob: When you're using git with svn, you can pull down the latest version only, or all versions. The default is all versions.

In fact, when I tried importing just the last version, it worked fine, but the first time I git svn dcommitt'd, it then fetch'd all past versions.

@Chris: git repo's are waaay small. They're like gzip, in that they recognize files (or portions of files?) that are identical between versions. Your 1tb repo might become 100mb if you do a full fetch then repack. Seriously.

@Damian, @Bob: I might still stay with svn, once v1.5 comes out, but git merges effectively push all changes from the merged branch into the mergee, *individually*, at the time of the original change. The individual commits are intact, in other words. In contrast, in svn and cvs, you have a single "merged trunk to this branch" commit. Not as natural.
Steve Willer
Thursday, 17 April 2008 16:20:15 UTC
A bit of data about repo size:
I have a 438MB svn repo which I've imported into git. The .git repo is 137MB. So that's about 1/3 size.
Steve Willer
Thursday, 17 April 2008 20:49:04 UTC
@Steve In that case I would have lost all of my file history so it would be smaller but I am not sure it is for a good reason (I kind of like to have the history). As a point of scale our repository has 300+ million files and the current compressed size using gzip compression is just over 2 tarabytes.

While GIT may work for small project or orgs I am just not sure how it scales to something very large.

Thanks for the response.
Chris Patterson
Friday, 18 April 2008 02:14:42 UTC
Okay, but just to clarify, in case I was unclear: you can import all version history into git, or just since revision X.

My test, which got the 1/3 ratio, was for a full import of every version.

That said, I haven't tried it with a 300m file repo ... I have no idea if it scales that large. That seems insanely large .... I'm amazed svn could handle it!
Steve Willer
Saturday, 19 April 2008 10:23:52 UTC
Interesting. I knew nothing about Git.
I wonder if it is practical to use it on Windows using Cygwin;
and if it is, how is the overall experience compared to svn? (considering tools, integration with VS, ...)
Sunday, 20 April 2008 19:49:07 UTC
Okay, I ran "git gc" on my test repo, and it's down to 118mb. That's versus the 438mb svn repo, or about 1/4 size.

Git has a lot of interesting use cases outside the limited domain of "svn/cvs replacement". It's worth reading to get an idea of other ways it can be used (e.g. as a generic undo mechanism for arbitrary files like configs in /etc).

@Bahador: there's a git package built into cygwin. There's also a more regular native port using mingw, but I haven't used it. No Tortoise equivalent yet. :-(
Steve Willer
Sunday, 20 April 2008 21:31:16 UTC
@Steve: Thanks.
Wednesday, 23 April 2008 18:21:08 UTC

We don't use SVN we use TFS.
Chris Patterson
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.