Anybody using GIT?

**VectraMan** · 24 April 2008, 10:38

Linus whatshisname can't even make an installable OS.

Bazaar is another one that has the idea of distributed repositorys. I can see the advantage if you have several small teams, or possibly if you have people who can't always access a single central server (but then it's getting increasingly difficult to be offline these days), but it's not really any different to using several different branches in something like SVN. And it seems to me the further you go off in different paths, the harder the merging it all together is going to be.

But then if you can't see the advantage of source control, there may be no hope for you. I'll soon be working on something from scratch and by myself, but I still intend to use SVN.

**Maca** · 24 April 2008, 10:45

I can see the point in Source Control it's just the overhead of using a tool to achieve what can be done manually that I question. In my experience a manual approach also encourages communication. Anyway, I don't want to get into a discussion about there being no hope for me etc.

Isn't merging the whole point? Show me a large team that doesn't merge regularly and I'll show you a lot of small teams.

The point Linus is making in the video is that SVN et al don't assume branching by default. They make it into a big deal, an exception to the rule almost.

I've worked on a 50 man development team, controlled by Clearcase, when, truely, only a couple of people were actually doing any work that was 'making a difference'.

**VectraMan** · 24 April 2008, 10:52

So for every single line of code you manually keep track of who changed it, what they changed, when they did it, and why they did it? Blimey - I'd hate to see your filing system.

I guess what GIT is saying is that you can keep several sets of personal revisions before you reach a stage where you commit and let everybody else have your changes. Which sounds quite good now I think about it.

**Maca** · 24 April 2008, 11:11

Originally posted by VectraMan View Post

So for every single line of code you manually keep track of who changed it, what they changed, when they did it, and why they did it? Blimey - I'd hate to see your filing system.

Why would I want to do that?

No, don't answer that please.

Look, I can see where you're going with this and I really don't want to get into that discussion. It's missing the point.

Did you watch the video? I assume you're saying that you don't agree with his views on CVS/SVN. If you want to say why then please do but try and be objective.

**VectraMan** · 24 April 2008, 12:49

I did watch bits of the video. Sounds quite good I have to say, though it's clearly aimed at the "lots of enthusiastic amateurs" approach of open source, and perhaps wouldn't fit so well in a commerical operation where people are paid to do things properly and people are paid to manage it. Not that I think managers are a good idea - give me better tools and eliminate management any day.

The fundamental problem with CVS is that it's file based, which SubVersioN solves. He was a bit too dismissive of SVN without really justifying it: you could do the same thing as GIT with multiple branches, although organising that for a large team is a bit of a pain, and the performance benefits of GIT are only really from accessing local data rather than remote data, which is becoming less and less of an issue.

But you're partly right about what you were saying originally: you have to be sure that the benefits of a fancy new system are worth the effort. You're wrong about source control not being worth it, even for a team of one, but I doubt GIT is worth it over SVN for a small team.

**beercohol** · 24 April 2008, 12:58

Originally posted by VectraMan View Post

I guess what GIT is saying is that you can keep several sets of personal revisions before you reach a stage where you commit and let everybody else have your changes. Which sounds quite good now I think about it.

Is that the same as Visual Studio TFS Source Control 'Shelving' (but without the 'distributed' bit)?

Oh, sorry thats a terrible question. I am going for a lunch pint with the team.

**Maca** · 24 April 2008, 13:01

Source Control doesn't necessarily imply a tool to me. In practice, I tend not to use a tool such as SVN, or Perforce, until I have a real baseline, i.e. a deliverable that has some worth. Then it's under Change Control.

All too often I've seen projects crippled by being under change control before the fundamental design architecture had settled. This quite often caused the wrong decisions to be made. Rather than checking it all out and refactoring it people would try horse-shoeing the new functionality into an inappropriate design. By the time the first delivery was due the code already looked like it had been under maintenance for 5 years.

I think the definition of a baseline is what's important and Change Control is obviously vital but is that automatically solved by using a Source Control tool?

**VectraMan** · 24 April 2008, 14:29

Originally posted by Maca View Post

Source Control doesn't necessarily imply a tool to me. In practice, I tend not to use a tool such as SVN, or Perforce, until I have a real baseline, i.e. a deliverable that has some worth. Then it's under Change Control.

Even in the initial stages, it's useful to regularly commit to source control and keep a history of changes. If you go down a dead end, or just break something that you had working, then it gives you an easy way of looking back. Of course you can do that with backups, or worse using #ifs on your changes, but source control does that better.

And of course it solves the problem of multiple developers working on the same files.

If you do discover the design is fundamentally wrong, well you can always just ditch that tree and start afresh. There's also something to be said for doing that anyway once you reached a baseline. There's little point in a released product having history all the way back to the initial developer creating the first source file.

Part of what GIT is saying is that people tend to do exactly what you do: i.e. not commit something until it's reached a baseline, and that problem is solved by giving individuals their own mini-source controls.

Sounds like I'm becoming a convert to GIT. I don't think there's a Tortoise GIT though, and I don't do command lines.

Anybody using GIT?