Re: GIT vs Other: Need argument

On Wed, 18 Apr 2007, Johannes Schindelin wrote:

It's a bit more work to set up though, and it has a lot less mindshare, and testing, obviously.

So yes, windows is a step-child. I'd love for it to not be one, and we'll get there, but it's clearly not as supported as the unix side. We still use a fair number of shell scripts (which in turn use unix commands and pipelines).

We'll get away from it. I think GSoC will help here.

Actually, at this stage, I really think cogito just *complicates* git usage. It hasn't been well-supported lately, and asking for help with cogito means that a lot of people can't help you. And you still end up using git commands for anything fancier.

So I don't think it's even true that new people should be pointed at cg any more.

What _is_ true is that git is simply different from CVS. I don't think it's necessarily harder to understand or use (in fact, I would argue that git is a lot _easier_ to understand), but it is *different*, and it has a ton more capabilities.

But compare setting up a git repository with setting up a CVS repository. With git, it's literally "git init", and you're done. No need to worry about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to get into, by comparison.

But being different means that *if* you already know CVS, you actually have a lot of unlearning of idiotic and bad habits, _and_ you need to learn that things that were so hard and scary under CVS that you either never learnt them, or quickly learnt to avoid ("branches" and "merging") are just so _easy_ under git, that they are discussed in the very first chapters of "getting started".

I can pretty much guarantee that 95% of all CVS users have never done a branch or a merge, even if they have used it for *years*. And yet, in git, we kind of take both of those for granted, and make them visible pretty much from day one.

Git is just *easier*. But it is also different, and people are used to things being so hard that you'd never use them.

In a CVS world, you never even *need* to learn about branches and merging, because no normal user is ever actually expected to use either. In contrast, in the git world, pretty much every project uses multiple branches, and you are introduced to them at a minimum as the "origin" branches even for projects that just have one. So you're getting all these concepts that were so hard in CVS that you never ever even learnt to do them!

So people coming from CVS/SVN have a double shock: they are supposed to learn things that they "know" are hard (because CVS/SVN made them so damn hard - don't tell me that SVN branching is easy, because it is *not* easy. It may be cheaper to create a branch, but it has _all_ the same idiocies that CVS has once it's created). And on top of that, they have to re-learn something new.

So I really don't think cogito is the answer any more. The answer simply is: you have to learn that branches are *simple*. That's a big hurdle for some people. It's not the learning part that is hard, it's the *unlearning*. CVS/SVN has taught people that some things are complicated, and git uses those "complicated" things every day.

People who come from a CVS background would be *shocked* to learn that I do multiple merges a day. In fact, in the two years we've used git, we've had 3300 merges - and that's just counting the *nontrivial* ones that didn't just fast-forward. That's roughly an *average* of 4.5 merges a day. EVERY DAY. For two years.

In the CVS/SVN kind of mindset, a merge is something you do once a month, and you gird your loins for it. And it's usually just an expert, and only used for complex projects. A normal user would _never_ do a merge!

			Linus