You know, I actually expected that the opposite would happen: GitHub would start offering Mercurial hosting.
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
GitHub is already pretty firmly entrenched in the Git community. I will say, however, that Bitbucket has one primary advantage over GitHub: Unlimited private repositories, with the cost being based on how many collaborators you have. If Bitbucket really promotes this angle, I could see a lot of small development teams moving to Bitbucket, and possibly taking their talent with them. So, if Bitbucket really pushes the "unlimited private repositories" angle, then they could begin taking back market share from GitHub.
GitHub is indeed a sort of social-network for developers working on open-source projects, and this makes it really attractive. Their interface is also totally kick-ass and I love them.
But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too.
I am very excited that Bitbucket is offering Git as an option, as Mercurial for me is not really compelling; not that Git is necessarily better but it's what I know and have absolutely no reason to learn yet-another-tool-that-does-the-same-thing.
> But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too.
Ditto. There's a number of projects that I just won't put online because I'd rather lose than share them. With Bitbucket it looks like I'll be able to stash them privately, for free.
I'm totally psyched that Bitbucket has given this good a plan as their base/free package.
> There's a number of projects that I just won't put online because I'd rather lose than share them.
Assuming that those projects don't generate much revenue for you [1], what's the point of keeping them private?
From a political point of view, I always see such projects as a good opportunity to promote Free Software. From an economic point of view, I like to put some pressure on my competitors that way. For really valuable stuff, I'm using strict licenses like GPLv3 or AGPLv3 which ensure that sharing won't result in any disadvantage for me.
So I really wonder (as a seriously meant question!) what kind of projects you are talking about. What kind of non/small-revenue project would anyone rather lose than share?
[1] Otherwise I'd wonder why you couldn't afford paying GitHub, and also couldn't afford to switch to Mercurial for hosting them on BitBucket for free.
I work on self-developed projects as a consultant that I don't have the rights to open source. Because of that, I need to use Github's paid account plan, even though I'm the only person who contributes code to that project. So, I'll be seriously considering bitbucket as an alternative host, because it could save me ~£85/year.
What about incomplete projects? Messy/hacky experiments? Completely idiotic/backwards stuff done for fun? Play-projects purely attempted for "ha I did it!"? Legally-grey (or blatantly illegal) projects? Or even school projects? I have hundreds of projects that fit in those categories, and none will ever be made publicly available. Sometimes it's just not good form to make a project public, other times it's clearly harmful to do so.
Nevertheless, I preserve my projects privately just in case I ever resume work on a whim, or want to reference what I did in the past (or more likely, what I did wrong). And now I can put them online privately for free, sharing with those I deem appropriate.
It depends on what you mean by "incomplete". 50 lines of code which do almost nothing useful are probably not worth publishing. But why not publishing a half-complete project? Publishing may help you find contributors. And the early feedback helps you to decide if your project is worth more intense attention.
> Messy/hacky experiments?
If the code is not too bad, I publish even that stuff (as long as it is big enough to be notable), e.g.
Depending on how much trouble this might cause, you probably shouldn't upload it anywhere. Even a "private" repository on GitHub/BitBucket might be too risky.
On the other hand, I know about a Free Software clone of a game that used the original graphics and music. Not quite legal, but the game was very old and the right holders obviously didn't care. However, after publishing the project got a little fan base that eventually included graphic designers and musicians, who replaced the proprietary stuff step by step with their own creations. So the game changed from "legally-grey" to "solid free". This would never have been possible if the game hadn't been published.
> Or even school projects?
My school projects were about the first ones I published, and I'm pretty proud about what I wrote in that age, e.g.
However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
> Depending on how much trouble this might cause, you probably shouldn't
> upload it anywhere. Even a "private" repository on GitHub/BitBucket might
> be too risky.
I don't think that he was talking about using BitBucket to host your malware
repo. Probably more along the lines of projects that aid in the downloading of
possibly copyrighted music/videos (for example). It's a legal grey area because
you really don't know if your are on the wrong side of a law until a court
makes a decision since there is no clear-cut way to know.
Some other examples:
1. You want to keep track of your dotfiles that you use at work. In general,
this may be ok to put public, but it may contain work-specific stuff
(hostnames, configurations, etc) that might get you in trouble for publishing
publicly. For example, my work shell config has aliases that include connection
information (sans password) to internal databases.
2. Resumes and/or cover letters. If you update your resume to say that you're
looking for work, or looking for work in another area, this could give info to
your current employer that you don't want to hand out. You might also want to
keep your cover letters in version control if you use something like LaTeX or
have specfic parts that you want to be boilerplate (e.g. description of
yourself and/or your exerience). If you keep this in public, then everyone
knows when/where you are applying for work, which may not be desirable even if
your employer doesn't care.
On the other hand, I know about a Free Software clone of a game that used the original graphics and music. Not quite legal, but the game was very old and the right holders obviously didn't care. However, after publishing the project got a little fan base that eventually included graphic designers and musicians, who replaced the proprietary stuff step by step with their own creations. So the game changed from "legally-grey" to "solid free". This would never have been possible if the game hadn't been published.
I voted you up specifically for this bit. This is great.
What game was cloned, and what is the name of the clone?
Sounds an awful lot like he's talking about OpenTTD, a "clone" of Transport Tycoon Deluxe that has some "interesting" history even aside from the media assets.
> However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
Which is why (lite) private repoes would be nice. I wouldn't want to hand out all the answers to my school assignments but I'd still like to keep them tracked with git (depending on the size). At the moment I've just put my coding folder inside Dropbox which in a way acts like version control (in the sense that I won't lose the code.
This term means that a proprietary game has been rewritten completely from scratch as a Free Software project.
Usually, the game principle stays the same, but has its own codebase, and different graphics and music. Sometimes names are changed, too, if the original names were trademarked. After some time, the Free Software clones usually surpass the original game in almost every aspect.
This is a great way for a fan community to push forward their favorite game long after the producers lost their (commercial) interest in it.
This is also some kind of sustainability, as it ensures the game won't die with the hardware it was produced for.
I can afford to upgrade my Github account, but I'm a bit cheap when it comes to doing so.
I do a lot of experimentation and I'm of the opinion that not everything I do is worthy of sharing. I've partially written a web interface for pianobar, a feed to rss translator for reformatting NOAA forecasts (they discontinued the REST service), some wiki-like software, and even some barebones PBX interfaces for an Asterisk replacement.
The work that I have put on Github hasn't seen a ton of interest—not that they're terribly complete. But I did write a simple-but-useful-enough asynchronous "cron"[1] system for Go (BSD licensed). I got only 1 comment questioning how I implemented it with a qualified "good job" (if that).
I'm no Ryan Bates or Linus Torvalds. Several times I've interacted with OSS projects, run into trouble, and asked relevant questions. But because I'm not a linux/unix guru I get flamed (I just bought a Mac 16 months ago, gimme a break).
Why expose myself? I'm not trying to flame you, but I did want to express my long-standing disappointment with the "friendliness" of a number of communities (HN included).
> I'm of the opinion that not everything I do is worthy of sharing
The same is true for me. But who defines what is "worthy of sharing"? I believe this question is to be answered by others, not by oneself. It's generally hard to say whether something will be interesting or uninteresting to others, i.e. worthy or unworthy of sharing.
I've seen some surprises in the past after publishing pet projects which I thought weren't worth much, and weren't really complete. Nevertheless, some of them did get interest, and with the help of others they did become good and almost complete.
Of course there are also other projects which I published, which nobody else was interested in, where I finally lost interest and which are hopelessly outdated crap by now.
However, I couldn't have told you in advance which of my projects will or will not share this fate.
Having that said, I fully agree that one shouldn't publish every crap. But I have quite good experiences with: When in doubt, publish!
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
This sums up my feelings exactly. I'm emphatically not a fan of the Github guys (who seem rather unprofessional), but the community is too big to ignore. I'll probably switch if/when they support hg, unless Atlassian can find a way to encourage a much more robust community in Bitbucket.
(And no, Github fans, hg-git is not "support" for hg.)
Not the OP, but I sent a friendly note asking a question that was perhaps a bit dumb--just asking to clarify what one "collaborator" meant to them. The response I got back was a bit rude.
Keep in mind my email said I was choosing a subscription plan. As someone who has done support, being rude to people about to purchase your service is even dumber than the question I asked...
I encountered something similar as well with their subscription plans. This was before a friend pointed me to Bitbucket, at which I've been very happy since.
A lot of people/companies I know were using Assembla and Beanstalk.
I wonder how big a threat this is to them, rather than Github .
I notice that Bitbucket hasnt integrated Issues tracker with git. Bitbucket's bug tracking was IMHO much superior to github.
Plus Bitbucket doesnt format the README markdown as nicely as Github.
EDIT: I notice that I was mistaken. you need to enable bug tracking from the admin tab.
Partially agree about the threat. This news generates a lot of marketing that could drive new users to Bitbucket instead of Assembla and Beanstalk. But for existing users (I've been using Assembla for a while for private repos) there is probably a lot less reason to switch over.
no. That analogy doesn't fit here. A closer one would be more like Linux supporting FAT32 natively because someone took the time to write proper support for it in an system it wasn't originally designed for (and it works beautifully with almost no corner cases).
It may not perform as well but I get to use what I want and still interoperate.
Fair enough; your analogy is better. But not for the reason you point out.
Because FAT32 naming conventions are radically different from Linux', and because it supports radically different directory restrictions, and because it has attributes that Linux doesn't understand, and because it doesn't support permissions, I have to always keep clearly in mind when I've mounted a FAT32 volume v. basically anything else. Yes, I can mount it, and it works just fine until it doesn't.
This is my experience with hg-git. Mercurial tags can be moved, Git tags can't be, so I need to keep that in mind. Mercurial signatures don't map to Git ones for obvious reasons or vice-versa, so I can't actually figure out whether a given release was signed by the project author. Mercurial branches lack Git analogs, so I have to remember not to use them. Mercurial bookmarks map to Git branches, so I have to be ready for bookmarks to move in odd ways as Git users work with my hg-git repository. Mercurial's multiple heads per branch have no real analog in Git (they'd be up for garbage collection). This list goes on.
When I use hg-git, I have to always keep the Git model in my head, AND keep the Mercurial model in my head, AND keep in mind how those two models interact. This isn't fun, and it's not anything remotely close to transparent. It's amazingly impressive how well hg-git works, but claiming that GitHub supports Mercurial due to hg-git is horribly misleading.
The hg-git abstraction is not very solid. You end up having to "think git" rather than "think hg" and my beef with git isn't in the syntax, it's in git.
If I'm going to use hg-git, I might as well use git itself. I don't want to use git; I want to use hg.
Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with.
I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there.
hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.)
To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me.
(I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
I don't think user-friendliness should be a primary goal for a version control system. The reason being that this is something we use day in and day out for years, so the importance of the learning curve is dwarfed by the power of the UI and the workflows it enables.
When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn.
In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked.
As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
I do think that user-friendliness must be a primary goal for a VCS, because I have to get people who aren't hardcore, balls-to-the-wall programmers to use it if I need to store their data in my tree. Hg can be picked up by those folks in short order and requires no "grokking" beyond what you can read on Spolsky's HG Init in half an hour minutes. (I have in the past worked with designers who were wholly out of their element with anything beyond HTML, CSS, and very simple jQuery-backed JavaScript; expecting them to "grok" their VCS was more of a demand than I wanted to make because I'd have had to teach them.) And, to be honest, I think having to "grok" your VCS is only slightly less ridiculous of a requirement for software to force upon its user than is having to "grok" your text editor. Similarly, is why I don't use vim and do use Sublime Text.
I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =)
(And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)
On text editors -- picking up Emacs was one of the hardest thing I ever did, as I had to learn new shortcuts, I had to learn to rely on the keyboard-only and I also had to learn some ELisp just to be able to configure it.
Because Emacs has some problems (it is hard to create new syntax-highlighting definitions, plugins break all the time, ELPA for package management is useless), I did try both Textmate and Sublime Text 2, several times.
But I keep going back to Emacs and personally I don't get how people can stand a text editor that doesn't even have proper UNDO (Textmate) or a text editor that doesn't have a workflow that is totally mouse-free. Emacs is also wonderful because it grows with you. Some things that should be simple are too hard indeed, but at least you can fix that.
Basically me switching to Emacs was similar to when I learned to touch-type. I did suffer, but productivity was increased tenfold in the end.
IMHO, you're not a user to require UI friendliness. The difference between a developer and a user is that users are using these applications casually. But if your day job is depending on a text editor, you should use the text editor that stays the least in your way, and friendliness has nothing to do with it. Ditto for version control.
On a side-note, race-car drivers in general do not use automatic transmissions. That's because they can change gears more efficiently than a computer can and because they don't need to eat sandwiches while driving.
I am comfortable in Emacs and quite good with vim. Both do get in my way, which is why I moved to Sublime Text for text editing.
I don't live in my text editor. I spend most of my time in IntelliJ or Visual Studio. The conventions of normal text editors are largely established, and so something that runs counter to those normal conventions--an emacs or a vim--do get in my way. It is a mental gearshift to go "oh, I need to do something different now", which is a drain on my concentration and a way to get annoyed and off track because I tried to go Ctrl-A in Visual Studio and it didn't do what I wanted it to do. The productivity benefit of not having to make my brain go modal or instantly remap my mental keybindings to use emacs even outweighed losing the extensions I liked (vimwiki has been largely replaced by Evernote for me now).
And, yes, VS or IntelliJ are more important than my text editor. They win by default--"Well, use vim/emacs for everything!" is unacceptable for reasons that should be obvious. Vim and emacs are nonstandard at their own peril, and conforming to them is a worse use of my time than using something that conforms to expectations.
That you don't "get" how I can stand it is OK; the important thing is that I can.
I spend most of my time in IntelliJ or Visual Studio.
It's understandable then why you don't like Vim/Emacs. Yes, working with IntelliJ/Eclipse/Visual Studio is painful for me too.
True anecdote - whenever I'm working with Eclipse, I have a shortcut that opens the current file in Emacs for me.
Vim and emacs are nonstandard at their own peril
I spend my time with Unix-related tools mostly, and Emacs/Vim shortcuts are not as nonstandard as you think. The Bash shell for instance uses Emacs shortcuts. In fact, all shells (like irb or ipython) powered by Readline also use Emacs shortcuts.
That you don't "get" how I can stand it is OK;
the important thing is that I can.
Don't take it as a criticism on yourself; I said that mostly because I'm pretty annoyed with Textmate - it does some things really well but other (IMHO important) features are totally retarded.
The analogy to text editors is bad though, since everyone can choose the UI they like for text editing, whereas for source control the choice of UIs is much reduced.
In other words, I can choose Vim/Emacs, slog away and get proficient, and someone else can read my code with notepad. With VCS, I'm asking casual and hardcore users to use the same UI, so it better appeal to both.
Yeah, I don't have those people in any meaningful capacity. If I did then hg would immediately be a strong contender.
With regards to the philosophical difference, I see where you're coming from. This is the reason I use OS X instead of Linux for instance, it's more important for me to have a simple and usable GUI than to have ultimate control and flexibility. With text editors and version control systems I don't feel that way though. As a matter of fact, I do use vim, and I don't think it's ridiculous in the least to use tools that require "grokking" for one's core competency. I'm not saying everyone should use these tools, but I do believe in my heart that the power of vim can not be equalled by a more user-friendly text editor. Sure you can have a more powerful IDE for language X or Y, but I doubt any of those will be able to stick around and grow with me over the dozens of languages I will use over the course of my career. Since I plan to use these tools for decades (unlike programming languages themselves), the importance of newbie-friendliness approaches zero. That's not to say the UI doesn't matter, but just that the factors that matter are the ones that are applicable to the master rather than the apprentice.
I never said "newbie-friendliness," though I can see how that might have been implied by my last post. I said "user-friendliness", which I think also lends itself to easier uptake from novices. Sorry for the confusion.
I know vim quite well. I still consider it onerous and unpleasant to use, and I find claims of its "power" to be overstated; I have noted before and still think to be true that editing text isn't the hard part of my job. I am definitely suspicious of claims that "it'll still be there in ten years" to be hugely important; my editor might change in ten years, but Cmd-X will still be cut and Cmd-V will still be paste, you know what I mean? The specifics of exactly what text editor I use matter so much less to me than "does it not make me hate using it?".
All of that is an aside, however, and tangential to what I was saying: for me, the visceral reaction to both vim and git is not a pleasant one; I find them to be designed for people whose mental model with regards to computer interaction is alien to mine, and despite being capable with both I find such tools uncomfortable to use. I don't consider either user-friendly (and, I think, to most people), and while I don't begrudge those who prefer those tools, life is simply too short to spend my time squeezing blood out of that particular stone.
> Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan.
I've seen this opinion espoused by others and I just don't understand it. I'd never ever use a VCS anymore that didn't let me "rewrite history". "git filter-branch" has saved me many hours of commit-work on multiple occasions--I just can't see why not having those kind of tools is considered a good thing.
Bzr is adamantly anti-amend and now the main Emacs repo has 10 megs of binary junk in the history that some developer accidentally checked in and pushed one day. Tell me why that is a good thing?
But look at it this way: What would github gain by adding mercurial support?
They're insanely popular and becoming more so by the minute, and their biggest problems probably have to do with managing growth, not lack of users. With git itself becoming increasingly popular, there's absolutely no sense that git will be a limiting factor any time in the future.
They clearly do recognize the long-term advantages in improving the usability of git, and have been making moves in that direction (iphone client, increasing the functionality of their web interface, some interaction on the git dev list), but hg's purported UI advantages are tenuous at best, and it seems a much surer bet to consolidate their position and improve git instead of investing a lot of effort in supporting hg, which would only _dilute_ their position.
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
GitHub is already pretty firmly entrenched in the Git community. I will say, however, that Bitbucket has one primary advantage over GitHub: Unlimited private repositories, with the cost being based on how many collaborators you have. If Bitbucket really promotes this angle, I could see a lot of small development teams moving to Bitbucket, and possibly taking their talent with them. So, if Bitbucket really pushes the "unlimited private repositories" angle, then they could begin taking back market share from GitHub.