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.
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).
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.
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.
Nowadays the choice between git and mercurial comes down mostly to preferring on the user interface over another.
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!!
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?
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.
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.
Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios:
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. :-)
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?
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.
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?
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.
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.
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.
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.
In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.
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.
- 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
The popularity would actually be the sum of both.
This was all early-2009, though. I wonder if git's increasing popularity has swayed the core PHP developers?
As a rational human, I look at that data and conclude that the survey was inconclusive.
PHP developers are less likely to be affected by that.
We won't know until someone writes a DVCS in PHP..
The main thing (to me) git has going for it, is GitHub. Even though BitBucket is getting better; it's still not GitHub.
Oh, and that's the reason why the mail states that they'll now figure out how to move php-src to git.
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.
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.
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.
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.
- PHP Internals Lurker
I don't see what difference having a git.php.net repo vs a github one will make. It's the same vcs...
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
 Unless you count mirrors, in which case both Linux and PHP are 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?
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.
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.
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.
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.
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.
the huge majority doesn't appear to be able
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?
If you want that sort of conversation, go to reddit.
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.
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.