> Github would probably not have succeeded had git's command line interface been better? What rubbish.
Indeed. Except that it's your words, not mine.
I wrote: "Github mainly succeeded because of the various shortcomings in Gits command line interface."
The message, which apparently needs to be spelled out is that using a repo through a command line is a hard thing to do for many developers nowadays who think the command line is something for people with long beards. By putting a friendly face - and a web based face no less - on a really nice open source distributed repository tool github did exactly that which you need to do to gain mass adoption:
Make something people need easy to use and do it in a way they can afford. Then iterate like crazy to dig out a defensible moat around the basic core.
Github blew the doors of the competition including some corporate heavyweights by capitalizing on Git and the trend of collaboration in software development. If they had had to develop git from scratch, if git would have come with a web based front end or if an established competitor (say sourceforge) would have adopted git earlier or (when git was still just for open source nerds and SVN, mercurial or some other repo system used more for corporate) they would have had a much harder time of it.
History happened the way it did for a reason and git being very powerful but somewhat harder to use gave github an opening that they used to create a spectacular success.
Opportunities arise all the time, how you make use of them is what matters and without git as it was there would be no github today.
But why would I rephrase what the git guys said so eloquently on their first homepage:
"git repository hosting
no longer a pain in the ass"
And:
"GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease. "
I stand by my comment. I see no clear difference in meaning between your wording and my rewording.
> "Github mainly succeeded because of the various shortcomings in Gits command line interface."
The success of github has nothing to do with shortcomings in git's CLI. As you say, for some people, the command line is for beards. So for them any CLI is a non-starter; nothing to do with shortcomings with git's CLI. The power available to a command line user of git is one of the reasons github is such a good thing.
Indeed. Except that it's your words, not mine.
I wrote: "Github mainly succeeded because of the various shortcomings in Gits command line interface."
The message, which apparently needs to be spelled out is that using a repo through a command line is a hard thing to do for many developers nowadays who think the command line is something for people with long beards. By putting a friendly face - and a web based face no less - on a really nice open source distributed repository tool github did exactly that which you need to do to gain mass adoption:
Make something people need easy to use and do it in a way they can afford. Then iterate like crazy to dig out a defensible moat around the basic core.
Github blew the doors of the competition including some corporate heavyweights by capitalizing on Git and the trend of collaboration in software development. If they had had to develop git from scratch, if git would have come with a web based front end or if an established competitor (say sourceforge) would have adopted git earlier or (when git was still just for open source nerds and SVN, mercurial or some other repo system used more for corporate) they would have had a much harder time of it.
History happened the way it did for a reason and git being very powerful but somewhat harder to use gave github an opening that they used to create a spectacular success.
Opportunities arise all the time, how you make use of them is what matters and without git as it was there would be no github today.
But why would I rephrase what the git guys said so eloquently on their first homepage:
"git repository hosting no longer a pain in the ass"
And:
"GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease. "
http://web.archive.org/web/20080514210148/http://github.com/