Feeds

back to article For FORK'S sake: GitHub checks out Windows client

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

This topic is closed for new posts.
JDX
Gold badge

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
Bronze badge

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
Silver badge
Thumb Down

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
Silver badge

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

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
Thumb Down

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
Silver badge

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
Thumb Up

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
Silver badge

Thanks for alerting me to fossil - that looks interesting. And +1 for Mercurial.

0
1
Meh

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

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
Thumb Down

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
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
Thumb Down

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
Bronze badge
Happy

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
Silver badge

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

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
Anonymous Coward

Re: Branching good, GIT BAD

Whatever, I use both everyday.

0
0
Coffee/keyboard

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

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
Silver badge
Thumb Up

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
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
Silver badge
Devil

Re: Apples and Oranges @Charlie Clark

I want my lolly!

1
0
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
Silver badge

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
Anonymous Coward

Windows?

Do they want it to crash all the time?

2
5
Silver badge

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
JDX
Gold badge

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
Silver badge

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
Silver badge

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
Silver badge

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
Silver badge
FAIL

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
Silver badge

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
Meh

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
Silver badge

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
Silver badge
FAIL

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

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

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
WTF?

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

0
0
MIc
Thumb Down

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
Silver badge

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
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
This topic is closed for new posts.