Just two years ago, Git barely eked out a mention in Forrester's analysis of the software configuration management (or source code management) market, despite a clear trend toward open-source SCM tools. Now Git owns 27.6 per cent of the SCM market, according to a recent Eclipse Foundation survey, with Subversion apparently in …

COMMENTS

House rules Send corrections

This topic is closed for new posts.

Tuesday 12th June 2012 09:27 GMT JDX

TortoiseGit? msysgit?

I am a newbie to git (and don't really like it) on Windows but both these existing tools have been invaluable for simple use against github, meaning I can get on with my work.

So saying there wasn't a GUI client before seems misleading. Unless they mean specifically a GUI app to configure things rather than work against a repo?

5 0
Tuesday 12th June 2012 09:33 GMT Matt 21

Feeling a little jaded

but.... I've never seen serious problems in a project due to the source control tool. Even sccs does the job. The problem always comes from people not using the tool and not following any kind of change control process so source control becomes "whatever we find in production".

0 0
1. Tuesday 12th June 2012 12:52 GMT Kubla Cant
  
  Re: Feeling a little jaded
  
  "I've never seen serious problems in a project due to the source control tool"
  
  Try working with Visual SourceSafe. Your experience will be widened, not in a good way.
  
  5 1
2. Tuesday 12th June 2012 19:26 GMT BlueGreen
  
  Re: Feeling a little jaded (@Matt 21)
  
  IME a problem is that many supposed developers aren't aware of version control and often dismissive of it if they do.
  
  However tool users can be even dumber than you can imagine. One workplace I took over a project and due to some remarkable competence of a consultant, we were using a VCS (unfortunately it was Visual SourceSafe, q.v. Kubla Cant's perspective). But I found the original owner of the project had decided to check in not only the code for a data conversion project, but the data for that project. A database of several gigs' size. From another continent too.
  
  BTW the data to be converted was not static either, so in a very short time it would have been outdated, thus making the initial data checkin totally pointless.
  
  0 0
Tuesday 12th June 2012 09:37 GMT 1Rafayal

I have never been a fan of open source SCM tools. I think this has been to do with my development background more than anything else.

For proprietary tools, you make a financial investment in terms of paying for installation and consultancy. For open source equivalents you make the investment in people instead. Probably they cost the same when it comes to money.

At home I have no problem using open source SCM tools, my favourite has been Mercurial. I think though the whole Git thing has passed me by somewhat.

GitHub for Windows will definitely be a fly in the ointment for companies that currently produce and support Git implementations for other SCM tools though - and it will make me seriously look at this tool for use at home and at work.

Sad, but true.

1 5
Tuesday 12th June 2012 09:49 GMT Antony Riley

And?

It doesn't change the fact that git was written by and for developers who live in a completely different world to developers who work on windows. Whilst there might have been some convergence between these two worlds in recent years they are still very far apart.

I wouldn't like to predict the meteoric rise of git or github to becoming the defacto industry standard, every few years a new one comes along.

2 2
1. Tuesday 12th June 2012 11:09 GMT DrXym
  
  Re: And?
  
  Msysgit definitely shows its Linux / Unix leanings but you can safely install and ignore it and interact solely through TortoiseGit which has very decent integration with Windows and is the defacto front end. A lot of IDEs also have integration or support for Git through plugins. There are even plugins for developer studio through a rival to TortoiseGit called Git Extensions.
  
  2 1
Tuesday 12th June 2012 09:49 GMT David Given

I've never been a fan of git; just the other day, I forked a github project, checked it out, and then a few days later upstream changed something in the past which meant that my fork now conflicted with the same release I forked it from... or something. I spent about a week fiddling with rebase trying to pull in their changes and eventually gave up and just reset my repository to their head. That's not impressive.

I do use Mercurial, though, and like it: much saner syntax and semantics that actually make sense. Plus it'll even interoperate with github (although hg-git is painfully slow for large projects; just for a stunt, I tried pulling in a linux kernel tree from github with it, and the checkout took 50 hours.)

The DVCS I'm thoroughly intrigued by, though, is fossil. Written by the sqlite guys, it's a tiny single executable that is a combined DVCS, bug tracker, wiki, web server, CGI script and GUI (via the built-in web server). No installation needed. Just the one executable basically gives you your own private github in a box. DVCS-wise it does immutable history and no rebasing, which I approve of. It also supports both decentralised mode (traditional DVCS) and centralised mode (traditional VCS). The only problem is that there's not much vendor support --- no Sourceforge of Google Projects support, for example, although it will import and export to git.

At work we use SVN. It's okay but is really slow, and merges lose history. I'd much rather use a DVCS, but there is more scope for shooting yourself in the foot that way.

2 2
1. Tuesday 12th June 2012 10:18 GMT Brewster's Angle Grinder
  
  Thanks for alerting me to fossil - that looks interesting. And +1 for Mercurial.
  
  0 1
  1. Tuesday 12th June 2012 13:12 GMT Anonymous Coward
    
    Another +1 for Mercurial. I use it at home for all my projects now.
    
    I came to the conclusion after reading http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
    
    Git I suspect will still have its uses, but I just can't see me willingly starting another project with SVN.
    
    0 1
2. Tuesday 12th June 2012 11:02 GMT Ben 50
  
  Similar experiences here...
  
  @David Given
  
  To be fair, I only used GIT when it was "shiny and new" - but real world usage was so different to all the "it's so easy, stupid" use cases that were out there at the time. At the point where I'd lost several days due to problems with rebase, and had to start digging into the GIT source code, I had one of those blinding flashes of the obvious - "it's not worth it" - and walked away.
  
  Perhaps things have changed, but on the otherhand, it was built for distributed open source projects. For small team driven closed source projects (which accounts for quite a lot of software development I think)... it struck me as a sub-optimal design.
  
  0 0
  1. Tuesday 12th June 2012 13:19 GMT David Dawson
    
    Re: Similar experiences here...
    
    I've used git quite a bit now, and the flash of inspiration on how to use it came when someone kept on insisting it be called a Distributed VCS.
    
    It doesn't work like SVN, but it can feel like it when you first get hold of it, and thats the danger, as it just doesn't
    
    Git is built to do branch merges exceptionally well, SVN has nothing comparable (many happy afternoons spent SVN merging, so I'm really not making this up). In git. you treat the upstream/ master branch as just another branch, and create lots of local branches to do your work within. Used this way (which is how it was always intended t be used) its way better to work with lots of people than SVN is.
    
    So, as an example, you should never do development on a local master branch. instead do it on a local dev branch so you can handle merging in the right direction (mitigating any issues with that you would end up using merge or rebase)
    
    My experience is that Git does take a bit of getting used to, but the payback is more than worth it (and the intellij git/ github integration is really quite good too), I'd never go back to svn or its ilk unless I'm forced to.
    
    3 0
Tuesday 12th June 2012 10:00 GMT Anonymous Coward

Branching good, GIT BAD

Sorry, while Linus Torvalds might be a low-level systems programming genius, as a designer of software that has to interface with a human he is a total retard, and GIT is the proof of this. Its command syntax and structure is utterly unintelligible and has not been designed with the good and obvious practice of making the common tasks simple.

If you want something that can do everything GIT does and more (and better), use Bazaar. It has a great command line interface and a great Qt GUI if you prefer that, old svn/cvs die-hards can use it in their backward way if they really want (allowing them to be nail-souped into doing it properly), PLUS Launchpad was much better than GitHub last time I checked, but I am sure this newfangled 'windows version' (of a web-service!?) will be a great improvement.

4 10
1. Tuesday 12th June 2012 10:49 GMT Anonymous Coward
  
  Re: Branching good, GIT BAD
  
  Torvalds didn't write GIT for end users. He wrote it for his specific requirements. He has said more than once that, given how popular his project has become, he's surprised that there are so few decent UIs.
  
  Calling someone a retard because they haven't done something they never said they'd do makes you look stupid to a degree that is hard to describe.
  
  Normally, I dislike it when people apologise before expressing an opinion. In your case, it makes perfect sense.
  
  10 4
  1. Tuesday 12th June 2012 10:54 GMT Anonymous Coward
    
    Re: Branching good, GIT BAD
    
    If he did say that then he is full of shit. Why did he release it publicly then? Why didn't he let someone redesign the command structure? I can imagine how that conversation would go - it would definitely result in Torvalds throwing a hissy fit.
    
    I retract my apology.
    
    4 14
    1. Tuesday 12th June 2012 11:05 GMT Anonymous Coward
      
      Re: Branching good, GIT BAD
      
      Let's remember that Linus has said that he has released software that is like him in one way or another, in one case it's called Linux and in the other it's called Git. No discontinuity there at all :)
      
      0 0
2. Tuesday 12th June 2012 11:11 GMT DrXym
  
  Re: Branching good, GIT BAD
  
  Linus turned over development a long time ago and the tools and syntax have improved a lot. It really isn't that bad even if you use the command line and most people wouldn't have to use the command line.
  
  0 0
  1. Tuesday 12th June 2012 17:10 GMT Anonymous Coward
    
    Re: Branching good, GIT BAD
    
    Nonsense, the syntax is so bad that the GUI tools are useless because to do anything useful you need non-default parameters to the commands and the GUI is built around the default commands. Try doing a revert from the GUI without losing all your work. Once I do a commit in Bazaar I can never lose that work (unless all the backups systems fail) which is as it should be.
    
    0 1
3. Tuesday 12th June 2012 16:51 GMT Lennart Sorensen
  
  Re: Branching good, GIT BAD
  
  Strangely I find bazaar to be the most incomprehensible command line I have seen in a long time. Git makes pretty good sense in most cases.
  
  Bazaar also does far less than git. If you don't know that, then you clearly haven't used it.
  
  1 0
  1. Tuesday 12th June 2012 17:03 GMT Anonymous Coward
    
    Re: Branching good, GIT BAD
    
    Whatever, I use both everyday.
    
    0 0
Tuesday 12th June 2012 10:06 GMT Anonymous Coward

Apples and Oranges

This article is plain wrong.

The Forrester's report appears to be across all the industry this latest one is just for Eclipse users. You can't compare the two! Git doesn't have 27% of the SCM market, just amongst Eclipse users.

7 0
1. Tuesday 12th June 2012 11:20 GMT Anonymous Coward
  
  Re: Apples and Oranges
  
  "This article is plain wrong." Huh, how can this be? And where is the spurious stock hyping MA usually sprays about?
  
  0 0
  1. Tuesday 12th June 2012 11:42 GMT Charlie Clark
    
    Re: Apples and Oranges
    
    Is anyone surprised? Par for the course, just missing something like "a valuation of $ 100 billion looks a bit small"!
    
    Still, he must be doing something right for El Reg to keep inviting him back on. I wonder if it works like this: Mr Asay writes something nice about some friends of his in the valley which is good for their next round of funding. The article gets lots of clicks and views on El Reg which is good for their figures. And we all get to show how clever we are by pointing out the elementary flaws in the argument. Win, win, win?
    
    2 1
    1. Tuesday 12th June 2012 13:38 GMT Anonymous Coward
      
      Re: Apples and Oranges @Charlie Clark
      
      Unfortunately your message is snowed under by your attacks on the authors of articles and sad accusatons of shilling. Just stick to pointing out flaws and you mght make your point instead of sounding like a petulant child. Too bad this sort of thing is getting too ingrained to stop now ...
      
      0 2
      1. Tuesday 12th June 2012 15:54 GMT Charlie Clark
        
        Re: Apples and Oranges @Charlie Clark
        
        I want my lolly!
        
        1 0
    2. Wednesday 13th June 2012 09:48 GMT Anonymous Coward
      
      Re: must be doing something right for El Reg to keep inviting him back on
      
      Has a neat byline. Although open and ignore might be more useful advice.
      
      So what am I doing here? There are quite a few Reg articles these days where the real information and useful opinion is ...in the comments.
      
      <<--- No icon. The old Reg Gravestone icon wore out.
      
      0 0
Tuesday 12th June 2012 10:27 GMT Paul Shirley

SVN in Eclipse deserves to die

I'm not surprised SVN is declining on Eclipse, the implementations are horribly fragile and I'm getting tired of manually fixing the repository when Eclipse gets itself out of sync. Eclipse also seems utterly incapable of creating new SVN projects on a Windows machine, have to fire up Tortoise or the command line to bootstrap it every time.

Probably time to bite the bullet and migrate.

0 0
Tuesday 12th June 2012 10:30 GMT Anonymous Coward

Windows?

Do they want it to crash all the time?

2 5
Tuesday 12th June 2012 11:02 GMT DrXym

EGit, TortoiseGit

It's very easy to develop with Git on windows. TortoiseGit (+ msysgit) is as easy to use as TortoiseSVN / CVS. And if you develop in Eclipse you can use EGit (+ JGit) which is fairly mature pure Java implementation.

The biggest issue is the old perennial of cross platform development - line endings. Git has auto line ending conversion but if you forget to set it your diffs can all be screwed up especially in EGit which still has a few bugs with it in 1.3.

Anyway, any business using Subversion or CVS really should seriously investigate git. In most ways it is vastly superior to either of these although some may argue that having to pull everything in a project rather than just a subfolder can be retrograde in some circumstances and workarounds like subprojects have all sorts of pitfalls.

0 0
1. Tuesday 12th June 2012 14:17 GMT JDX
  
  Re: EGit, TortoiseGit
  
  TortoiseGit seems very good to me, but it doesn't change the fundamental fact you still have to use Git. I'd much rather stay with TortoiseSVN!
  
  0 0
  1. Tuesday 12th June 2012 16:06 GMT DrXym
    
    Re: EGit, TortoiseGit
    
    There are things I'd still recommend subversion over git such as document / binary storage but for source control and collaborative development git is far superior.
    
    Trivial example. Emails go out to say the trunk is open / closed. I want to commit my changes but I can't because the trunk is closed. I could create a branch in svn to commit my changes but its such a pain in the arse and I still have to merge them back to trunk later. The usual course of action is to hold off on the commmit even though its ready and hope I don't pollute it with other changes. In git I just commit locally. Later on when the trunk / master is open I push. In git branch creation is so trivial I could even do the work on a throwaway branch free from other changes and then merge it back into my local master and push a bunch of similar commits all in one go.
    
    Another trivial example. There are two branches A and B representing work by two teams. In subversion I usually maintain two snapshots representing A and B and maintain them in separate workspaces. Double the overhead of keeping them up to date. In git I can choose separate clones if I really wish but equally I could manage both in a single clone and just switch between each branch on the fly.
    
    0 0
    1. Tuesday 12th June 2012 19:58 GMT BlueGreen
      
      Re: EGit, TortoiseGit
      
      Interesting post, not sure problems are clear to me.
      
      "Emails go out to say the trunk is open / closed. I want to commit my changes but I can't because the trunk is closed"
      
      You shouldn't be working on the trunk then, only on a branch for future merging (I understand this is best practice, I've never merged branches myself except as pratice).
      
      "In git I just commit locally. Later on when the trunk / master is open I push"
      
      Wot, no conflicts, evar? #Really?# Surely bitchslaps SVN into the middle of next week!
      
      "There are two branches A and B representing work by two teams. In subversion I usually maintain two snapshots representing A and B and maintain them in separate workspaces. Double the overhead of keeping them up to date"
      
      Well, I may be misunderstanding but a pair of svn update calls in a batch file will update both working copies, no hassle. Failing that, svn switch to, well, switch a single working copy between two branches.
      
      0 0
      1. Wednesday 13th June 2012 08:15 GMT DrXym
        
        Re: EGit, TortoiseGit
        
        "You shouldn't be working on the trunk then, only on a branch for future merging (I understand this is best practice, I've never merged branches myself except as pratice)."
        
        A more likely scenario is someone creates a build branch from the trunk and then builds that and cherry picks commits from the trunk if something is needed to fix an issue. Git can do this too of course but it's still more effort than what I suggested.
        
        "Wot, no conflicts, evar? #Really?# Surely bitchslaps SVN into the middle of next week!"
        
        Of course there are conflicts occasionally in pulling (a combined fetch and merge) but not when pushing providing your clone is up to date prior to the push.
        
        "Well, I may be misunderstanding but a pair of svn update calls in a batch file will update both working copies, no hassle. Failing that, svn switch to, well, switch a single working copy between two branches."
        
        So you can hack something which lessens the effort of kicking off two updates but you still have to do it. And an svn switch is nowhere near as elegant given that it involves substantial server round trips to perform. Switching a branch in git is completely local to the machine because all of the history is there. It is so trivial to create and switch branches with git that developers would routinely do it to discrete bug fixes.
        
        The simple fact is git is vastly superior to subversion in these scenarios. I've used enough source control systems to recognize their own individual strengths and weaknesses. Git (and mercurial) stomp CVS, Subversion and other VCS systems into a bloody pulp when it comes to scenarios like the above.
        
        0 0
2. Tuesday 12th June 2012 19:47 GMT BlueGreen
  
  Re: EGit, TortoiseGit
  
  "having to pull everything in a project rather than just a subfolder "
  
  No, you can update a subfolder (any subfolder) trivially, indeed I have entire distinct projects as subfolders in a single repo.
  
  0 0
  1. Wednesday 13th June 2012 08:33 GMT DrXym
    
    Re: EGit, TortoiseGit
    
    "No, you can update a subfolder (any subfolder) trivially, indeed I have entire distinct projects as subfolders in a single repo."
    
    I recognise git to be superior in most regards but being able to clone and make changes to a small part of a large project is not one of them. e.g. I might have an interest in 5 small config files which happen to reside in a project with a 30,000 other files in it. But I can't easily obtain those files without cloning the entire project. I could maybe do a shallow clone, but that only stops me grabbing history for the other 29,995 files not, but I'd still get the latest copies and of course a shallow clone would prevent me making modifications to the files if that was my intent. In cvs or svn I could just checkout the folder the files were in and ignore the rest.
    
    It may be the case that the project can sometimes use sub modules but that still does not satisfy ad hoc requests and also requires greater up front consideration of where the boundaries are. Sub modules are also a pain to deal with and would generally be used sparingly, e.g. one project making use of another entirely discrete project with a separate development cycle rather than developing and committing across all sub modules simultaneously. In fact that's how sub modules are designed to work with the .gitmodules pointing at a specific hash for each sub module and you having to explicitly update to pick up more recent changes.
    
    The workaround is probably to throw up a "community" clone for people to reference, or perhaps a web server. It's still not one of git's strong points though and I see no reason to defend it for that.
    
    0 0
Tuesday 12th June 2012 11:36 GMT Matware

Mercurial, just use it

I did a trade study while planning to move away from that terrible and expensive IBM product, and came to the conclusion that git is powerful, and git hub rocks. If you do development in mixed environments and want a seamless tool just use mercurial. Great windows integration, great visual studio integration, great command line... the one down side is the inability to flatten history (which I don't miss) and the number of ways you can branch leads to confusion.

To all the subversion users out there.... best practice for merging subversion branches is pulling the branches into mercurial, merge, then deliver the result back to subversion. Time to go DCVS.

To all the TortoiseGit and GitExtensions users out there. Try TortiseHG and Visual HG, you'll think you're doing it wrong because there was no swearing and arm waving.

But... I'll give the new git client a go.

2 0
1. Wednesday 13th June 2012 13:00 GMT DrXym
  
  Re: Mercurial, just use it
  
  If that IBM product is ClearCase then I sympathize. It has to be one of the most over engineered, expensive, convoluted pieces of crap I've ever had the misfortune to use. I recall one place of work hired several contractors whose job was to administer the large servers needed to mirror servers in the US. The latency in ClearCase was so awful that it was impossible to connect to those US servers directly so every site needed run batch files which synchronized changes between sites every 10 minutes or so, adding to the general mess of getting any work done. Even IBM gave up trying to fix it and produced a thick client to hide the latency. God I hated it.
  
  0 0
Tuesday 12th June 2012 11:48 GMT Charlie Clark

The right to fork

Git gets high marks for its commitment to the cardinal rule of open source: the right to fork

Ouch! Forking is easy with any VCS, it's merging that is so damn difficult and for which Git, Mercurial and Bazaar and others rightly get their attention.

DVCS have some great advantages such as allowing commits while offline but also some disadvantages especially on very large projects. Github really struggled when Haiku moved to it.

Anyway, although I'm one of the Mercurial fan boys, it's not really your choice of VCS that matters but that you have one at all.

0 0
1. Tuesday 12th June 2012 12:01 GMT 1Rafayal
  
  Re: The right to fork
  
  If we are talking about how easy it should be to merge, then you need to talk about closed source tools as well to put this into context.
  
  Tools like Accurev and Perforce do a great job of this - if you are willing to pay for them. Plus, there is a very established user base for these products.
  
  1 0
Tuesday 12th June 2012 13:37 GMT Anonymous Coward

My experience

I've used in a commercial context Perforce, IBM Synergy and Mercurial.

Perforce, IMO, beats everything hands down in all terms except price.

Synergy is complete pants and Mercurial looked interesting but I found it quickly got confusing.

0 0
Tuesday 12th June 2012 16:54 GMT Lennart Sorensen

I looked at the github for windows tool. I was highly disappointed to find that it is ONLY a github tool rather than a nice git tool for windows. What a sad waste of time. Why would you want to use a tool that only works with one site? Who wants that kind of vendor lockin? OK, I suppose they are targeting windows users, but still. Very disappointing.

0 0
Tuesday 12th June 2012 17:33 GMT Anonymous Coward

That's what I said, guess you didn't actually read my post before commenting on it?

0 0
Tuesday 12th June 2012 18:31 GMT MIc

When it...

integrates with a build server infra structure and allows me to enforce gated checkins based on unit test execution pass rates then I'll jump on board. And when it integrates with Visual Studio.

0 0
Tuesday 12th June 2012 20:22 GMT BlueGreen

Well offtopic but it might save some pain

TortoiseSVN can get its kex in a twist, giving the impression something is going seriously wrong. If this happens, drop to the cli and poke around. Invariably it's ok but it can be a bad moment.

0 0
Tuesday 12th June 2012 21:17 GMT Anonymous Coward

Uninstall fail

Doesn't support non-github remotes. Uninstall. Oh but wait, it doesn't remove the 50+M of data (git binaries and not sure what else) under AppData, and doesn't clean up the registry either.

0 0