Yay, a major project using hg instead of git. This makes it seem like my work on hg is still worth something (as are the pull requests I have sent to pygments).
Btw, the next hg sprint will be at Pycon in Montréal!
> Yay, a major project using hg instead of git. This makes it seem like my work on hg is still worth something (as are the pull requests I have sent to pygments).
Mostly because nobody spend time to make the move. All other pocoo projects move to git (Flask, Werkzeug, Jinja2, Click, Sphinx, etc.).
Whether or not hg is good or even better than git is pretty much irrelevant at this point.
Github's popularity has made all other project hosting platforms irrelevant. Git's popularity means that every potential contributor knows how to use it, which significantly reduces friction for new ones.
I don't buy the popularity argument. If I were to abandon software just because it wasn't as popular as the alternative, I would have to stop working on GNU Octave in favour of Matlab, and I would have to wipe GNU/Linux from my machines and just use Mac OS X or Windows.
I understand that git transcends organisation, programming languages, and operating systems. I still don't want to be stuck to the git way of doing things, no matter how popular it is. Concessions have to be made for git users coming to hg, but there are some things that hg does that git just will probably never be able to.
I may one day work on improving hgit, which is an hg front-end to a git storage backend proof-of-concept, but so far the hg-git workaround for git's popularity is good enough for most purposes.
Popularity is a strong argument. It's however not the only argument. In the case of git and hg popularity is important because the other arguments are too weak to matter in comparision.
That's not the case for GNU Octave or Linux. Those offer significant financial, ideological and technical benefits over alternatives. Benefits a large part of their user base actually cares about. Hg doesn't have that luxury. Git is simply good enough and hg is not good enough to offset the cost for choosing the unpopular option.
By this logic, Java and .net and php and sql are all irrelevant because all the cool kids use nodejs and mongodb, right?
The HN crowd loves to chase what's "trendy" without thought for if it's a good fit for their problem.
GitHub frankly is a terrible solution for anything but an open source project, and even then there are plenty of better alternatives.
if your project relies on the popularity of GitHub to attract contributors I would be more worried about the nature of your contributors than where the code is hosted.
I think for an open source project git itself has some nice features that are severely lacking in hg. Since I switched to git I never looked back and handling of pull requests has become a breeze. In hg times I actually shuffled around with mq and manually applied patches because managing other people's remotes in light of named branches was a nightmare.
I consider MQ one of hg's youthful mistakes, just like early git didn't have refs.
If your biggest complaint with hg is MQ, rejoice: there are modern alternatives that make MQ almost obsolete unless your current workflow already heavily depends on MQ.
Uh. Do you mean that, because a project is open source it has to limit itself to the lowest common denominator (not targeting git specifically here) rather than aspire to a better/more suited toolchain that its community believe in?
And by the community, I do not count those not having made any contribution but complaining about what is there in the first place.
This case is about the toolchain, but the same could be set about the code. Does it has to stick to an imperative form, as it is the most common widespread and understood paradigm, or can it be functional because it fits best the original design?
As long as the API is clean and the documentation is clear, I'm fine making the little extra effort to enter the world of the author rather than him/her lowering his/her expectation about what the project, as a whole, should be.
It's quite humorous to think about how Git's popularity is as a result of a platform that in many ways subverts its interface and even core architecture of being distributed. Is it a Pyrrhic victory, I cannot tell.
As does Facebook, Google, and Python and a few not as big players. I've also heard rumours that the Facebook devs are trying to help other big companies move slow, gigantic git repos to faster gigantic hg repos.
Still, it's a bit hard for me to keep my chin up over hg when everyone seems to think that git is the ultimate word on DVCSes with no room for dissenting software. It warms my heart whenever I see another project using hg for real and not half-heartedly like Golang was doing... and now they're using git half-heartedly, oh well.
For what it's worth, I think Hg is an easier sell to mid-size companies transitioning from SVN to a DVCS. With Git, you need to absorb a certain "git mentality" to really understand what all of the commands are; with Hg it seems like I just need to say "you COMMIT and UPDATE from this hidden folder on your drive, then you PUSH and PULL from that hidden folder to these other hidden folders in other places."
If it makes you feel better, at one point at this job I replayed a bunch of SVN changes through Hg because there were a bunch of independent updates that needed to be grouped into different branches, so that I could finally find out that the cause of the bugs in the code was that someone had changed `if (x == "true")` statements into `if (x)` statements...
Pygments for me has been easy to get working on my blog but extremely difficult and so far impossible for me to customize. My blog is Ruby based and so first of all I don't quite understand how a python program can be added as a ruby gem. Second, I really don't understand how to create my own lexer. Do I edit the Ruby gem? Do I need to create my own gem? If I edit the gem locally I may be able to do something but how do those edits get to Heroku? The task is much more complicated than I have the knowledge for.
I used Pygments to power the syntax colouring of ulisse (https://github.com/JulianBirch/ulisse) a Clojure documentation generator (specifically, a codox writer).
> The only problem is it is slow, so you can't view longer files immediately as in regular less.
For most lexers this could be fixed to be iterative. The lexers can do iterative processing, it's just that the command line tool does a horrible job at supporting that.
How about you contribute this missing bit or improve it instead of whining on the internet? This is really a minor feature for pyglets (most people would use it for more mainstream stuff than Agda), so how about you take it over?
Btw, the next hg sprint will be at Pycon in Montréal!
http://mercurial.selenic.com/wiki/3.4sprint