Scott Hanselman

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.

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!

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).

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?

David check out http://code.google.com/p/msysgit/downloads/list. You do not need cygwin using this.

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!

Ok,

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

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?

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.

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: 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.

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 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.

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!

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, ...)

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 http://www-cs-students.stanford.edu/~blynn/gitmagic/ 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: Thanks.

@Steve,

We don't use SVN we use TFS.