PHP will switch to git | Hacker News Reader

PHP will switch to git

news.php.net

221 pointstreffer102 comments

Git appears to be fast becoming the standard DVCS.

Is there any reason that all reasonably well-run projects should not be using git?

GitHub seems vastly superior to BitBucket, and git itself seems pretty much isomorphic to hg (albeit with worse syntax). (This ignores darcs, bzr, etc., but those never seemed terribly competitive for mindshare.) Furthermore, the network effects (with pull requests on Github, not having to have people learn a new DVCS to commit to your project, etc.) seem huge.

Aside from some new innovation on the scale of switching from a centralized VCS to a distributed VCS, I can't imagine anything that would cause me to try to start a project in something other than git, learn another VCS other than git, or try to convert someone to another VCS other than git. Is this the wrong attitude?

Is there any chance that Python might see the light and switch to git from hg? At this stage, choosing hg over git for reasons that seem increasingly irrelevant (better Windows support at the time, written in C/shell rather than Python) is starting to look like a worse and worse historical decision.

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

I keep seeing people talk about all the good of hg over git, but I haven't seen anything that really sets it apart.

If you were doing a sales pitch, what would you show that hg has over git? What are some specific plugins that ease your development or release process? What are some real-world advantages of the hg patch-queue over how git handles pulls?

I'm honestly curious. I just haven't seen anything to sell me on why hg is so much better than git (or even the other way around).

From the perspective of a longtime hg user who switched jobs and is now in git land: hg is easier to pick up and start using than git.

git lets you do incredible things with your tree, things that hg forbids or makes impossible. But git also lets you make big mistakes, and isn't very nice about helping you fix them.

hg, on the other hand, has a much nicer learning curve. As an example, try to forget everything you know about version control and type `hg help push` and `git help push`.

Which one would you be able to parse? Personally, when I read "The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>", I want to punch a baby.

At the end of the day, if I want to transition a team away from SVN onto a DVCS, I'd pick hg -- just because it lets a team Get Shit Done without spending a ton of time learning a new VCS. But if I'm starting my own project? I'd pick git in a heartbeat.

Besides the simplicity when starting to use a DVCS, i would add the simplicity for setting up a server (At least on Windows). There are a lot of organizations which need a centralized repo. And setting up mercurial for serving is a breeze. That's my 2 cents.

Next time you have to use git: Remember, there are also patch-queues for git.

Which do you use? I've had a quick google and only found Guilt as a serious contender, and that doesn't seem to quite do what hg patch queues do (especially wrt publishing queues). I'm interested as it seems like quite a common workflow (for me at least) that doesn't really fit into the Git model.

Have you come across this discussion (http://stackoverflow.com/questions/5016862/whats-the-git-app...)?

My co-workers use Guilt.

We had published patch-queues in another department I worked for, and they were one of the reasons they switched to git instead.

I've never warmed up to patch-queues, but I haven't really tried to use them seriously.

/me did not know this - thank you for the fill in (I'll stop preaching about them for hg then, I thought they were unique to hg!)

Also mercurial can do almost anything that git does (and more) with the right extensions.

Nowadays the choice between git and mercurial comes down mostly to preferring on the user interface over another.

I'm pretty addicted to git's lightweight branching now. Mercurial looks appealing in some ways but, from what I understand, it doesn't support anything similar, at least not in the core.

For heavier work, hg's patch queue's are unmatched. (not to mention you can version the patch queue as well!)

If bookmarks are too lightweight for something (say you have an experimental branch that you want to branch on-top of) patch queues are amazing.

Not to mention their ease of use!!

http://hgbook.red-bean.com/read/managing-change-with-mercuri...

You are thinking of Bookmarks, which have been a part of core since 1.8 and was an extension included with mercurial for a few versions prior.

Bookmarks mimic git's branches to some extent, but last time I tried they did not cope well with complicated merges.

I'm a Git guy myself, but FWIW: While Python seems to be the Mercurial project everyone remembers because it was the most recent biggie to adopt it, there's also Mozilla, and the Ex-Sun-now-Oracle projects and a couple of others.

Ah, very interesting list.

I guess I think of Python differently from the other projects in your list because the choice of DVCS chosen by the core team seems to me to impact the DVCS that someone will choose for their library in the language. I don't really have any evidence for that, however.

Do you think that (a) language communities tend to standardize on the same version control, and if so, (b) that language communities tend to standardize on the version control of the core project for the language?

I think (a) is true, yes. I've written about the migration of KDE from SVN to Git in a longer comment elsewhere in this thread, and Qt (not a language, but the library framework most of KDE's products build upon) switching to Git was definitely a significant factor in Git gaining traction among members of the KDE community. The KDE community consciously wanted to harness the potential synergy it saw in the KDE and Qt ecospheres syncing up on the same VCS.

OTOH, I think the Python community is pragmatic enough that it wouldn't have chosen Mercurial over Git if it being written in Python would have been the only point in Mercurial's favor, from the POV of their requirement set. But it probably does have an emotional/affinity effect, after all language developers do obviously have to care about language! :)

Interestingly, one of the best Git libraries around is actually a pure Python implementation of Git and its protocols: Dulwich.

As someone who choose hg over git w/o reviewing bitbucket vs github, I'm curious what makes github superior. Can you elaborate?

It is difficult to answer your question without knowing your purposes and goals. What aspects do you think would make a quality version control host?

For me, the primary issue is size.

A large number of people use Github. This means that social features like networks of forks of repositories and pull requests are substantially more compelling. This also means that many related websites (bug trackers, project managers) have Github integration. Further, it makes much more sense to design custom desktop apps for Github because it is what everyone uses. Lastly, the more people are familiar with Github, the easier it becomes to suggest it for a project or to contribute to a random Github-based project.

The APIs, UI, and general flow of Github are competently designed, but I do not think these are necessarily the core of its success. (I do believe these parts of Github, however, to be better than the competition.)

Ultimately, Github is in a unique position because of its (and git's) popularity. Social features that would not work on other sites work on Github. I am sure that the developers and designers of, e.g., BitBucket and Google Code are smart people, but without users they feel a little like ghost towns.

This is odd, because I had thought of VCS hosting as very much a commodity before Github.

Git appears to be fast becoming the standard DVCS.

Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios:

http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#...

Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-)

You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be:

http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+...

Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS).

However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

"is distributed version control so much better than centralized version control that we will all eventually be using a DVCS?"

I can't predict the future, but I do think DVCS is fundamentally superior. Joel Spolsky called it "possibly the biggest advance in software development technology in the ten years I’ve been writing articles here." (http://www.joelonsoftware.com/items/2010/03/17.html)

Let me describe a key weakness of centralized version control and how decentralizing fixes it.

Say you're working on a project with others. All of you commit to the repo, and you use it to deploy to production.

When you're coding experimentally, you have to make a choice: do I commit often, possibly giving half-baked code to my peers? Or do I commit only when I'm totally done, with long periods between commits, during which I can't roll back changes?

DVCS eliminates this painful choice. Commit as often as you like on your local repo. When your code is ready, push up to the shared repo. If you like, you can even do better: push up to a shared development branch for review and merging into the deployable branch. And better than that: if it took you 20 false steps to get to the end result, doing stuff, undoing it, redoing it differently, etc, you can clean up that commit history to a single, logical, readable commit for your teammates to read.

That is fundamentally better for teammwork. Add all the stuff about offline access, etc, and it's just clearly better.

DVCS eliminates this painful choice. Commit as often as you like on your local repo

I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox.

I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch.

How is my process any different than using Git?

Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc.

Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete.

Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc.

And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie.

tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.

In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness

Huh? Branching code in no way affects the code that has been branched.

Instead of a flat directory as your sandbox you've got a full VCS at your disposal

I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem.

So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.

> Branching code in no way affects the code that has been branched.

Usually it requires a repo admin - hence "team awareness".

> So far, the only advantage I see to Git is the ability to make offline commits

That's more important than you imagine. It also means nothing takes longer than a few seconds - branching, diffing, committing...

> I don't get it. I can make as many branches in Subversion as I want.

But you can't do it offline. You can't even check-in without the central server, let alone make and use branches, merge them, share them with another dev, etc.

When you're offline you aren't using a VCS at all.

> presumably they sync when I have a network connection

Hah, no. That's half the fun.

> However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

Well, I guess I must be one of those low quality developers, as I have yet to hear/read a compelling argument that would motivate me not to use SVN.

I have always considered the source control problem to be solved: distributed version control attempts to solve a problem that I don't have, and never had while working on major projects with distributed teams in the past.

I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.

Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?

Are you serious?

Was that necessary?

As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git.

Speed and disk space have never been an issue for me with cvs or Subversion. The content-tracking sounds interesting, but really, I don't rename files all that often.

it has a killer app in GitHub

That doesn't have any sway on my choice of version control. I sometimes retrieve files from GitHub, but that's about it.

I don't know, I haven't heard anything really compelling about git. People who use it seem really excited about it, but not for any reasons that strike me as particularly objective.

Please accept my apologies, my original response was a little OTT. The objective reasons for making the switch are:

- its a lot faster (IIRC creating a branch in subversion is the same as a copy operation) - the merging algorithm is better (this is so important IMO) - you get to commit when disconnected from the network - because it is faster and uses significantly less space, you can improve the way you segregate changes, giving you more (and improved) options when it comes to your branching strategy

To add further evidence toward your argument, consider also the alternative name, "svn":

http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2...

The popularity would actually be the sum of both.

Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`

The following link should provide the correct unions of job postings:

http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...

You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.

The votes are a stark contrast to those of the core Python developers when they were voting on which DVCS to migrate to[1]—although understandably they favoured Mercurial, they disfavoured git. (Bazaar got a good share of votes as well.) The victor's margin was much smaller.

This was all early-2009, though. I wonder if git's increasing popularity has swayed the core PHP developers?

[1] http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...

Look at the numbers for uninformed. Really what that survey showed is that the voters were uninformed about their choices.

As a rational human, I look at that data and conclude that the survey was inconclusive.

Not saying that I disagree, but how do you look at votes and conclude that those who cast them were uninformed? Or am I misunderstanding you?

If I understand correctly, there is an explicit 'uninformed' option to choose.

Oh we were talking about the Python votes, not the PHP ones, sorry.

Mercurial is written in Python - as a Python developer I can attest to the phenomenon of Python developers preferring software written in Python. Part of this is rational, part of this is pure "my tribe" bias (by the way, I use and like git, don't know Mercurial at all.)

PHP developers are less likely to be affected by that.

> PHP developers are less likely to be affected by that.

We won't know until someone writes a DVCS in PHP..

hmmmmmmm.....

To be fair, now there exist a library of git function written in pure python. http://www.samba.org/~jelmer/dulwich/

Interesting. I was a barely competent sysadmin that couldn't contain my interest in learning how to develop software. So, over the last 6 months I messed around with Vim and Emacs/ Git, Hg, and Bazaar/ and Erlang, Ruby, Lua and Python. I settled on Emacs, Python, and Git; however, the only choice I made that was overwhelmed by popularity was the choice of learning a DVCS because that is a central piece of the functionality: how easy it is to collaborate (as beginner I will fail w/o more informed collaborators). I realize I will have to spend lots of time on my chosen setup, but I hope in a few years I can make transitions more easily.

Mercurial has quite a few merits! I like git but I like hg better.

The main thing (to me) git has going for it, is GitHub. Even though BitBucket is getting better; it's still not GitHub.

OTOH, bitbucket has free private hosting and git doesn't (AFAIK). I think that is a crucial point for a beginner who is just learning to code and doesn't want to a) pay money, or b) have his ugly code be visible to the world.

Don't be afraid to show your code to the world. Better yet, paste some in a pastebin and ask for tips in an IRC channel: it'll make you a better developer.

It's often hard to get people on IRC to actually respond to a pastebin more than 15 lines long. IRC is good for "Can you tell you why my function is busted," but not so much for "How can I improve the architecture of my 500 line app". (The usual first answer to that, BTW, is "Reduce your 500 line app to 300 lines without removing any functionality")

Rasmus gave a talk yesterday and I asked if they were switching to github. He said they'd likely switch to git (it's now happening, apparently), but not github because it can't do ACLs and the PHP project has thousands of people who need commit access to various places.

exactly, they want to keep their karma system. But a github mirror is not unlikely.

Oh, and that's the reason why the mail states that they'll now figure out how to move php-src to git.

There is already a github mirror:

https://github.com/php/php-src

Wonder if they knew about GitHub Organizations?

https://github.com/blog/674-introducing-organizations

This only provides repo level access control. They want ACL's to control down to the branch level.

Think certially and not distributed there :-)

This is handled in projects like the Linux kernel.

Could easily enough have the commitor push to a different repo than he pulls from. Then you could have person manually review pull his changes into manager (like Linus does with Linux).. or if you wanted some automation, have a script import his changes if they match a set of rules.

The other option is submodules.

> Then you could have person manually review pull his changes into manager (like Linus does with Linux)

this assumes that there are enough trusted people in the PHP project with enough time to spend for doing nothing but reviewing pull requests.

> The other option is submodules.

that's a very good idea, especially when you consider how modularized PHP's build system already is. Give them time though. Moving from SVN to git is already a huge step in the right direction, even though the keep most of the old model the same.

Once all of that works nicely, a further step can be to move to submodules.

This sounds like a horribly broken development process to me. Is there any article that explains the idea behind this? I would really like to know how this could work.

Isn't decentralised and ACL is a bit of an oxymoron?

And plain Git can do ACLs? I didn't know that.

I assume you already know this, i.e. the above was sarcasm, but: No, it can't. But since remote access to Git most commonly happens over SSH, ACLs can be implemented by additional tools which serve as the login shell and filter the git commands the client wants to run. The best such tool right now is gitolite, building on concepts established by gitosis. The GitHub-like open source web repo manager Gitorious also implements an ACL system that way.

I was pretty sure, but I never know when I've missed some huge piece of functionality in a program. Thanks for the explanation.

Yep, it can.

Was there any official statement stating that they would switch to GitHub? All I see is that they're switching to git.

no; they aren't moving to github at least right now

There is no point in git-vs-hg debate. Main point is that PHP people are switching to DVCS.

Git is often chosen because it is more popular, has larger community and stuff-written-about-it.

Also, it has GitHub, which can be attributed for most of the huge boost of git popularity.

That does not neccessarily mean that git is better. Still, it is good enough for most of us (and them), and there is just no point in debating. PHP vote was not about which-is-better. It as about - which-one-to-chose.

Some folk jumping to conclusions in the comments here ...

The linked message is one post on an internal mailing list. It was intended as a summary of the votes, for the voters. It has no broader context of the situation they face or no links to any debates that might have happened before because of the audience it was aimed at.

If anyone from PHP internals wants to tell us about the background of this decision that would be really interesting.

This discussion has been going on for a about 1.5 months. Even before that actually, but the discussion that led to this move starts here:

http://marc.info/?l=php-internals&m=131275031209004&...

- PHP Internals Lurker

i hope they'll follow the trend and move it to github!

Why?

What treffer said. It'll be like the old days of sourceforge, just better and simpler. I love how easy it is to commit to projects on github. Also love the idea of a centralized place to follow all your favorite projects. If linux can be on github i would think php could as well.

PHP has been mirrored on github for awhile already if you want to follow it and stuff: https://github.com/php

I don't see what difference having a git.php.net repo vs a github one will make. It's the same vcs...

True, but git.php.net would be under their control with regards to what kind of infrastructure they want to set up on it. If they hosted it on GitHub, they would have to rely on GitHub's infrastructure instead of being able to develop and maintain their own.

FWIW, during KDE's (one of the largest open source communities around, with about 2500 active developer accounts with direct write access to many millions of lines of code across dozens of products, and large numbers of external contributors) ongoing migration from SVN to Git, GitHub was never considered as an option because the community considers it unacceptable for an open source community to throw their weight behind a proprietary solution.

Instead we seriously considered the open source alternative Gitorious.org for a while, but ultimately were unable to come to an agreement with Shortcut AS with regard to a satisfactory hosting plan, and also had troubles making its ACL system work for our needs in some exploratory migrations to the platform.

Self-hosting the Gitorious software also fell out of the running fairly quickly due to the ACL problems and other concerns about the software's features and implementation; while KDE probably would have been able to put together a squad of coders to work on the software in its interest, Shortcut at the time had failed to get a dev community around Gitorious off the ground and was unacceptably slow at processing merge requests - meaning a fork might have become necessary, which is always an icky proposition not to mention a big burden on resources.

Ultimately we ended up banging together our own Git infrastructure out of several smaller components, some of which we wrote ourselves:

* To handle access controls as well as the developer-facing repo management knobs (personal server-side clones, personal scratch repos, access management for those, a trashcan for repos, the works) we chose gitolite, which was definitely the best choice we could have made. It's reliable, well-documented, fast and rich in features, and its principal developer Sitaram Chamarty has been an incredible aid to our efforts both with many hours of work spent coding additional features we needed and tons of advice. We did write a couple of add-ins to gitolite ourselves to provide some additional commands to developers, which we found pleasant to do.

* As web-based repository viewer we use an inhouse-modified version of Redmine. As with gitolite, we've found the Redmine crew to be easy to approach and get help from, and while we ran into some trouble with the scalability of its Git support, it proved easy enough to modify without requiring massive forking. Redmine's database of projects serves a vital role in the system in that the gitolite config is generated from Redmine's database (e.g user access roles), and we also generate a custom-format XML from it that is used by end-user clone/build tools, our translation infrastructure, LXR and many other bits and pieces that have a need to discover projects and repositories and their metadata (which can be modified by project managers in the Redmine web UI, e.g. setting description texts or translation branches).

* For review, we use ReviewBoard, continuing on from SVN. This is definitely the weak spot in our setup right now; ReviewBoard just doesn't support Git very well since it's designed to handle single patches rather than series of them and thus also can't track branches. We've been looking at Gerrit on and off to replace it, but so far can't really bring ourselves to commit to it since it's a fairly unwieldy beast.

* We wrote our own repository hooks in Python, which are in charge of things like sending out commit mails to mailing lists, CIA.vc, the bug tracker and people mentioned in commit messages behind special keywords, evaluating other keywords to close bug tickets or review requests, check for trivial errors (EOL style, license headers, that sort of thing), ref backups and a bunch of other tasks. Some of which run through asynchronous job queues as required to avoid blocking.

* We wrote our own mirroring system to provide several read-only git:// mirror servers behind a geo-ip DNS load balancer. The mirrors get updated whenever a push to the master happens.

* KDE has an LDAP-based single sign-on system in use at many of its web properties including Redmine and ReviewBoard, currently using an inhouse-modified (mostly expanded with our own modules) version of GOsa as web frontend. GOsa is also used to request developer privileges and manage the SSH keys for Git write access.

* There are a couple of other minor bits and pieces flying about, like a commits.kde.org/<repoid/<abbreviated or full sha1> web app written in Ruby+Sinatra that forwards to the Redmine page for the commit; those URLs pop up in various places, e.g. in a developer's terminal output after pushing, in mail headers, CIA.vc postings, etc.

KDE's migration to Git is still ongoing, with many large and actively developed codebases still remaining in SVN at this time, as well as the entire translation effort. To actually migrate things we use our own tool called svn2git which takes raw SVN repo data, an account conversion map (supplied as plain text generated from our LDAP) and a plain text file with regex-based rules as input and produces git repositories. Writing the necessary rules files is unfortunately a time-intensive task especially given some very complex project histories originally imported from CVS, but additional tools exist to partially auto-generate them by analyzing SVN history programmatically.

Here's a couple of links of interest:

* The developer-facing user manual for KDE's Git infra: http://community.kde.org/Sysadmin/GitKdeOrgManual

* The initial posting of the sysadmin working group's plan for the above setup, and our evaluation of this stack vs. the Gitorious software (ODF of the latter is attached to the first reply): http://mail.kde.org/pipermail/kde-scm-interest/2010-June/001...

* The XML export from Redmine mentioned above: https://projects.kde.org/kde_projects.xml

Isn't a major selling point of GitHub the fact that you don't have to develop and maintain your own infrastructure, because they've already set everything up for you?

Linux is not on github[1]. A temporary mirror of it is, since kernel.org is down.

[1] Unless you count mirrors, in which case both Linux and PHP are on github.

>I love how easy it is to commit to projects on github

It's as simple to commit projects to github as it is to sf, bitbucket, google code, etc. Wait... you need to set up ssh credentials on github... sorry, it's more difficult to commit a project to github than it is to most of the alternatives.

>Also love the idea of a centralized place to follow all your favorite projects.

It's good that we like different things. I love the FACT that there can't be such place, it's technically not possible, fortunately!

>If linux can be on github i would think php could as well.

Linux is not on github, Linus Torvalds has one of his branches of the linux kernel on github, doesn't mean that he doesn't push his commits to other places too, which he certainly does. Also, linux is much more than the kernel, and its bits are hosted in literally thousands of different places. Finally, you can maintain your branch of the linux kernel wherever you wish, there's no mystical force forcing everybody to use Linus', you can use whatever kernel build you want from whatever sources you want. So saying "linux is on github" is a rather vague sentence.

Don't get me wrong, I like github, I would hate not having a reason to. It appears to me that most of the people don't relaly know why they like github. Because it's popular maybe?

nothing to do with being "cool". Github have created a great piece of management software to view and manage your git repositories. It's easy to use and that is why its popular not used because its popular. Git itself is popular because its easier to use than SVN and is decentralized which is very useful.

> Github have created a great piece of management software to view and manage your git repositories

Therein lies the problem, and why it's not a good collaboration space for everyone (as has been implied elsewhere in this thread). I won't use it simply because I dislike dealing with git, for example. Yes, it's a great tool if you want to use git. The mentality I've seen become more prevalent over the last year to two years, however, is that you must be on Github to "do open source right"--setting aside the obvious silliness of that, it does still exist in a lot of places.

If they supported hg with the same infrastructure, I'd consider switching off of bitbucket, but given the Github folks' public behaviors in the past, it wouldn't be a guarantee. I've been treated very well by Atlassian and don't think particularly highly of the Github guys.

> It's as simple to commit projects to github as it is to sf, bitbucket, google code, etc. Wait... you need to set up ssh credentials on github... sorry, it's more difficult to commit a project to github than it is to most of the alternatives.

You can just as easily use it over HTTPS and use your github login (which is how a lot of SVN repos are setup).

SF, BitBucket, Google Code, et. all are no easier or harder than GitHub for getting access. You have to register for all of them and setup your credentials for the repo on all of them.

To be fair, it's easier to commit to a project on Github. There's an 'edit' button, which lets you make changes inline on the website.

Google Code also has this feature.

because github is one of the most visible and most visited source hosting sites?

I still don't get your point. It's the most visited source hosting site, no doubt about that, so...?

On the subject of the topic, I'm getting tired of this git euforia. The linked message says zero about the reason beyond a simple direct voting. So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did? Sounds like a pretty useless voting for me. Well, except if you want to be popular and use all the tools the cool kids use these days, I guess that's a valid reason. Something tells me that there will be less 'I'm too cool to say positive things about PHP' kind of threads in HN.

Well Git is simply great. It's fast, it's powerful, there's a very helpful community, it's integrated everywhere, there are well made and useful online repository (Yes Github, but others too), the list goes on and on. Yes, there are bazaar, mercurial and probably dozen of others, but there's also git.

I'm not sure I get your point. I think what you don't like is that they chose to jump on git without real reason instead of carefully comparing other alternatives. It might be true.. or it might not. All great programmers try various version control.. if the majority of them prefered Git for their personal projects, why not switch to it? And, for open source project, Github is really just too useful.

My point is rather simple: Everybody is jumping in the git/github bandwagen but the huge majority doesn't appear to be able to state practical advantage of git besides github popularity. That is my point.

Not saying that there are no advantages, but heck, changing to something else because "it should be good, everyone else is doing it" is plain stupid... and very silly. And those are attributes we wouldn't want to welcome to the hackers' community.

Who are "we"? Someone making assumptions about the motivation of others?

  the huge majority doesn't appear to be able

How do you know that? Did you interview the huge majority yourself? Git has many important advantages over svn and they are no secret.

ever heard of the network effect?

Well, I mean, there's a reason all the cool kids are using git these days, and it's not just to "look cool".

to be fair the reason is outlined in the post. "... move to a decentralized version control system."

bazaar and mercurial are decentralized too, so that would only rule out SVN.

> The linked message says zero about the reason beyond a simple direct voting.

The linked message is a single posting from thousands to an internal message list, of course it doesn't. A quick search for "git" on the PHP internals list shows lots of posts.

> So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did?

Jumping to conclusions much?

I, for one, am happy it's not the other way round

PHP should switch to Django instead.

Haha. You beat me to it!

I went from 999 to 992. I guess I should have kept my mouth shut, but it was worth it. But tbh, I have nothing against PHP; it was just a joke.

Wow, I went from 999 to 964.. that's 35 down-votes! This is insane, but not surprising coming from PHP folks. (Too serious to laugh, too stupid to switch, too stubborn to think, too old to learn, amen.)

It isn't PHP folks who are down voting you, it's the Hacker News community. You didn't add anything to this conversation, so you were down voted. Please read the guidelines: http://ycombinator.com/newsguidelines.html

If you want that sort of conversation, go to reddit.

Point taken. :) Sorry. Removing my post (and taking most of this thread with it.)

EDIT: Except I didn't realize I can't do that after folks have replied. Anyways, it's pretty clear a lot of folks didn't find it funny or appreciate it. I went from about 90 karma to 55 or so. Sorry to be a bother.

No problem. Everyone makes mistakes. Just learn from your experience and move on. We try to keep a high level of conversation here. Please try to keep things civil, and make comments that actually add to the conversation. Thanks :)

924, and continuing. That'll make a nice karma average. We see clearly the revenge of the PHP dumpshit.

And it was a good joke!

I worked with PHP from 2004 to 2010. I worked with PEAR packages, early-adopted and watched the evolution of Zend Framework, ran both the local PHP user group and company's internal PHP user group, used ORM solutions like Doctrine and wrote my own, laughed along when people were handing out "Fails" stickers at php|tek (a play on the Rails logo), helped write some PHP coursework in college, etc. If I can't poke fun at PHP, who can?

I started using Rails for personal projects last year. When the opportunity arose, I was happy to join a consulting company that primarily uses Rails for web-based application development. Rails 3 (and now Rails 3.1) is awesome. Your joke is my recommendation to the folks I worked with that still do PHP all day: Check out some of the other things that are going on in the Ruby and Python communities. The developer experience is so much better.

Reply on news.ycombinator.com