Bitbucket now rocks Git
blog.bitbucket.org
blog.bitbucket.org
I wonder if/how GitHub will respond. I strongly prefer their UI and already have a paid plan, but I find myself shuffling repos within the confines of that plan rather than stomaching the (admittedly not very big) upgrade cost since many of the projects aren't super important. I understand why they do it, but I just don't like that they place an arbitrary restriction on the number of private repos.
I'm currently paying for a prgmr instance just to run gitolite (https://github.com/sitaramc/gitolite) so I could have a private place to store remotes for my repos. I'm planning to move to bitbucket immediately.
Let's put it this way:
* on GitHub, thanks to our repo count, we would be a $200/mo Platinum account
* on Bitbucket, thanks to our user count, we would be a $0/mo Free account, although we might have to upgrade all the way up to a $10/mo account as we're adding some people.
Needless to say, I will be looking hard at Bitbucket now that they're supporting Git.
You're talking about the number limit?
I guess this answers your question. I'm a happy Github customer myself (both personally as well as with my company), but it is interesting to see Bitbucket compete with them head-on. I can see quite a lot of small/medium companies move over.
I could see GH creating an "unlimited" account for $20/month that allows up to 3mb of files and unlimited repos.
I just wonder if there's a bit of a culture-jam here. It'd tempt you to not open up projects as freely, which seems at odds with the ideals of the GH camp.
They have a great business model - free repos for OSS drives users, then they get users to pay a smallish (in absolute terms) cost for private repos. All they need is the million odd developers who use their system for OSS, and they will shake a few bucks out of each somehow. There's no need for them and BB to compete as though they were selling commodity products. Both are competing on getting people used to their interface (by OSS products) and then charging then whatever they think won't cause too much pain.
That said, people with lots of small repos are feeling unnecessary pain from Github's pricing scheme.
What is a user?
Someone with read or write access to one of your private repositories.
I wonder if it makes sense for github to have a 'lite' repo that is just straight up storage, no extra features. This would be valuable to me because even though I can set up a bitbucket account and get the free private repos, I just like having everything in one place. I feel like they could even tack on a small amount to the normal subscription fee, or be able to add these on a la carte for an added monthly cost.
Don't get me wrong, I love the collaborative features and UI when I am working on the project with others, but for solo projects and old projects I don't update often this would be great.
BitBucket is very good from a pricing and support point of view (and I actually preferred Mercurial before I learnt Git properly) but it's not nearly as polished as GitHub - one thing that springs to mind (it might have been fixed) was it trying to show me a complete diff of Xcode project files when I clicked on a commit causing my browser to crash. Pretty much the main reason I switched.
I'd be really keen to see some real competition in the hosted social-coding space (it's funny, that sentence wouldn't have made sense just a few years ago), and Atlassian has the resources to do it.
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.
It may not perform as well but I get to use what I want and still interoperate.
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.
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.)
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 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.)
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 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.
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
That you don't "get" how I can stand it is OK;
the important thing is that I can.
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.
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 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.
> but Cmd-X will still be cut and Cmd-V will
> still be paste
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?
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.
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.)
How so? They're quite snappy with the support in my experience, and handled the firesheep situation much better than most companies.
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 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.
How so?
Git isn't what attracts most people to 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.
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.
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.
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.
http://pypi.python.org/pypi/vserver
> Completely idiotic/backwards stuff done for fun?
I recently published such a project and got surprisingly great feedback:
http://news.ycombinator.com/item?id=3061050
> Play-projects purely attempted for "ha I did it!"?
Why not? You never know who'll like it anyway, e.g.
http://sourceforge.net/projects/hosh/
> Legally-grey (or blatantly illegal) projects?
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.
http://sourceforge.net/projects/voji/
http://sourceforge.net/projects/volt/
Later I also published some notable university project works (sorry, German language):
However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
I voted you up specifically for this bit. This is great.
What game was cloned, and what is the name of the clone?
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.
> 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.
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.
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).
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!
> I'd rather lose than share them
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.
Running businesses with "lets offer more for free" and "ohh crap, they offer more for free, lets lower our price" is a race to the bottom.
It is actually moves like these that make me question Bitbucket more. How viable is the service long term? Do I want to trust all my own code to them?
It doesn't cost them a lot more in infrastructure to provide alternate dvcs - so your point seems to be completly invalid. More and more I'm starting to think that git is some kind of religion.
We benefit from competition between those 2 platforms and in the end this is what should count the most for us - customers.
One point, however, rings true: competition is good for we end-users, and it's certainly exciting that Bitbucket now offers both hg and git access.
To me it's opening to customers with different demands.
My opinion stems from running my own SaaS applications, seen the business downsides of all the free stuff, and now don't focus very much on the free aspect. I prefer trial.
I also recognize that me paying for a service I like is a healthy way to help that service stay around, because that is how I view it when my customers are paying me.
You are choosing to use Bitbucket for specific reasons. If they shut down because Atlassian is burning money and wants to trim the bottom line, then you now need to find something else to fill those specific needs again.
You don't lose any code, but you now need to figure something else out. And if you were relying on "free unlimited private repositories" you might not find that on another and now have to pay for something else.
Personally, I use GitHub daily for my job, but my private code isn't with GitHub.
On any available machine with some free space and an SSH daemon?
You talk about "figuring something else out" like it's some sort of big project. I don't understand that at all. There's no really effective lock-in here, users can take their repos and go anywhere or nowhere with negligible effort. They could even easily maintain a full copy of their repos on some backup machine at all times while using bitbucket or github.
And they can always increase the number of repos in each plan. I understand this won't make them as competitive on pricing, but the better user experience they offer has to be reflected in the cost.
Compare it to Github's slick UI: https://github.com/blog/760-the-tree-slider
But I am optimistic Bitbucket will change it for the better.
I completely agree that UI's something we need to improve on. I do think we've been making progress: We recently redesigned the commit history page, we've cleaned up the repository and account admin pages, and we've been updating the whole site with a more streamlined look and feel.
One of the next big things on our roadmap is redoing the repository header (that thing with all the tabs and buttons). And personally, I'd like to see us standardize on a single repo landing page with everything you need, but that's a little controversial at the moment. :)
We're huge fans of defunkt's pjax library, so expect to see it used more on the site in the future - including in the source browser.
Oh, and we're currently looking for a designer! http://www.atlassian.com/about/careers/listing.jsp?jobID=143
I think the competitive advantage for Bitbucket will come from super-enhancing features like the issue tracker. Today, I still have to run Redmine inspite of having Github issues. Give me an industrial quality issue tracker (hooks, assignee features, charting, roles and permissions).
Basically just pull Bugzilla into Bitbucket. Now, that would be a killer feature !
TL;DR : will pay for issues
However, github's UI is really exceptional. Things like the slide-over really make it a smooth experience.
My feedback is that hg is solid, bitbucket guts are solid, and the UI is what's really holding you back (besides the git fanboys hollering really loudly).
See: https://bitbucket.org/ellislab/codeigniter-reactor/
Every major block element on that page except for the very top page navigation has a white background. The project info box has a white background, the branches/tags/etc controls bar has a white background, the commit table has a white background, the footer has a white background - all matching (and failing to stand out from) the page's own white background.
Compare to: https://github.com/rails/rails
The use of varying grays and even a blue background help separate elements from each other, as well as separate them from the page background that they're on top of.
I'm not a designer, but the one thing that has always turned me off from Bitbucket is feeling like I'm looking at a bunch of visual clutter whenever I first look at a page. And it's not because there is a lot of visual clutter (there isn't) but simply because everything on the whole page is on the same white background and, at first glance, just blurs into each other.
Great news (and thanks)! However, please s/wrote/written/
EDIT: I see they fixed the copy.
http://confluence.atlassian.com/display/BITBUCKET/Bitbucket+... - shows error message "Unable to render {include} The included page could not be found."
I really like GitHub Issues though. Does Bitbucket have anything similar? I don't see it on their site.
You can see one at https://bitbucket.org/jespern/django-piston/issues?status=ne...
Could it be that if they might use Bitbucket as an entry point to their products? Perhaps with more integration.
=== Thank you for signing up for Bitbucket!
You are currently on the 5 Users plan. You can always upgrade your plan to add more collaborators.
We're excited that you're getting started with Mercurial, arguably the best distributed version control system around. We've put together some great resources to get you up and running quickly so that your team can focus on building great software faster.
Cheers, The Atlassian Bitbucket team ===
If you're even semi-serious about development, paying $7/month is nothing for the value they provide.
I wouldn't expect GitHub to compete directly with BitBucket's pricing, but doubling the amount of private repos allowed wouldn't hurt.
Github's pricing policy seems to strongly encourage community and collaboration, and it works wonders.
If it has something to do with their main business (say something to manage their server commands easily) or is integrated into another one of their tools the cost open sourcing it may not be worth it.
For me, I specifically make a lot of my work public to avoid someone else claiming sole invention rights--as I have reasonable public proof of prior art. Though to this day this has never happened, and people have always given my projects more than appropriate credit without even having to ask.
I used to think like your parent. Then I got over myself and just push everything to a a public github repo. So what if most of my project have no watchers and no forks. It can't hurt anything (except maybe my ego?). Once I did the transition with one of my bigger projects, I've nerver looked back.
Private repositories are for "serious" companies. Public repository are for "serious" developers.
I've had a Bitbucket account for a while and never used it, mainly because I'm more comfortable with git. But after poking around Bitbucket and importing some repos I'm seeing that you really get what you pay for.
GitHub completely trounces Bitbucket with their ease of use and toolset. I hope Bitbucket can step it up.
If I encrypt my drive, convert it to ASCII, and upload it, will they host it?
Seriously, though, the limitations of git and mercurial with respect to large files probably prevent them from having to deal with this kind of thing.
[1] http://news.ycombinator.com/item?id=3068576
[2] Unconfirmed by me. http://news.ycombinator.com/item?id=3067107
Bitbucket gets what I need. I love the social coding of GitHub and will continue to participate in it. But I can't put my own projects there. There's too many small, private repos that I can't keep paying for.
Bitbucket's approach is good for me. I'd rather pay for storage/users than per repo. If Github is really about promoting source code control, it shouldn't be a barrier for private / personal projects. For now, bitbucket solves this. I hope Github comes around.
Until then, I'm cancelling my $7 github account and giving Bitbucket $10/month even though I'm only using 2 users. They're doing me a real service and favor.
bitbucket for your private repos, promote to github for when they become open-source to benefit from the larger community
i believe github might end up charging for public repos, rather than reducing the prices for private ones ;)
Please tell me (frown face) that this feature isn't just for new repos....
It's something we might revisit in the distant future. As a middle ground, I've been thinking of implementing support for multiple SCMs in a single repository with the conversion/syncing process left up to the user. But that'll probably take more than a couple of 20% days to bang out. :)
If you're interested, I have some patches against hg-git that make it easier to take an existing Hg repo and convert it to Git (as opposed to the other way around). I haven't had a chance to prepare them to go upstream yet, but my repo's here: [link redacted]
Quick question from someone new to Bitbucket:
I have to authenticate every time I push to the repo. I've added my SSH key to the account, but I assume there's some additional configuration, such as how github has you add values for github.user and github.token to your global git config, but I can't find any such info for what those variables need to be for Bitbucket - assuming that's the reason I'm still continually prompted for a password.
Has anyone sorted this out yet or got SSH authentication working with Git & Bitbucket?
I was able to upload an existing repo I had by:
1) Uploading my SSH Public Key at https://bitbucket.org/account/ (i.e. the contents of ~/.ssh/id_rsa.pub) 2) Create a blank repo at Bitbucket 3) Adding a remote (git remote add bitbucket git@bitbucket.org:{username}/{reponame}.git) 4) Pushing to bitbucket (git push bitbucket master)
The most important parts were adding my SSH Public Key, and making sure to use git@bitbucket.org:{username}/{reponame}.git instead of any https links you might see on bitbucket.
I must say that I wish there was a middle road between bitbucket and github pricing: I like to pay enough money to to be fair. I will eventually have about 20 small repos, most of which I won't use very often. Solo developer.
It would not cost much at all to support a user such as myself, so if the cost were about $5/month that would be better than free. That said, it is so easy to move git hosting back to one of my EC2s, that if they decide to not provide this service in the future it is only a small hassle.
I just backed up my Github stuff using Github-backup and added them to Codeplane. Honestly surprised nobody challenged GitHub in pricing until recently. As far as social coding goes they are the Facebook of repo hosting (SourceForge is Friendster and Google Code is MySpace).
A while back I had chosen bitbucket over GitHub because of the free private repository. And Git was not an absolute requirement, non-Git source control was absolutely fine.
GitHub still does not offer a private repo for free (currently private is $7/month), I imagine this may change at some point soon now.
The greatest strength they have over Github right now is unlimited private git repositories (github only allows 1 private repo for free accounts), free of charge.
True, it preps users for other Atlassian products; and marginal cost of storage is near-zero these days.
Has any popular git hosting site added mercurial support?
This shows which DVCS is winning.
Developers are religious. Whether it is vi vs emacs, or IDEA vs Eclipse or Mac vs Linux. In September we had a huge debate internally (hundreds of comments long) on functional vs non-functional programming.
We know that no-one wins in these religious debates.
We've found that developers are equally religious regarding their DVCS. Most frequently it is whatever DVCS you started with is the one that you're passionate about.
We've found that most companies of any size have both Git and Mercurial lurking somewhere in their development ranks. Previously if they wanted to host their code in the cloud (and who wouldn't), they would have had to choose two different hosting providers. As a developer, this was a pain as you never knew where your code was.
Now that Bitbucket supports both, you no longer have to choose. We think this is a huge win! Companies can store all their code in one place. And with the per-user pricing, it is a very fair pricing model (don't have to think about whether a fork is going to cost you or not!).
We've used both Github and Beanstalkapp.com and both charge based on total repos rather then disk space or developers which, frankly, drives me a bit insane. I think both have better features then bitbucket (as far as I am aware) and better UI's (subjective) but my 60 small repos run me $100/month at beanstalk - not sure what it would run @ github.
I can't find any disk usage limits @ BB's site, which makes me wonder if there are hidden caps. If BB ever struck me as being as slick as github, I'd move our business in a second, even if the cost was higher then it is now ($10 a month? Really?!).
We don't want our pricing to be based on repos, or disk space, or any other limitation that is hard to predict, or encourages sub-optimal decision making to optimise cost. We think that users is the best way to price a product, and is easy to predict.
In terms of UI - there are things that bug me today, but our team is cranking along improving it.
But we have found that most of our users spend their time interacting via the command-line, and therefore we have prioritised features around stability and performance, as well as enabling Git support. Now that this is done, we'll be focusing more time on UI again.
Let me ask you about a particular case then :). I am in a group that develops a natural language parser for Dutch. It's open source, but so far we have been hosting it in a private Subversion repository on our university servers. We do provide a read-only (somewhat hidden) git mirror of the tree, but we have considered publishing it as an public git repository, but were always worried that the repository is too large for hosting it externally.
The git repository has existed for one and a half year, and the bare repo is currently 1098 MB in size*. Would hosting such a repository on Bitbucket be considered fair-use?
And let me clarify: by fair-use we mean we offer unlimited _code_ hosting, not general storage. We monitor for abuse, such as large repos containing only music, videos, and public viruses or malware. Though don't worry - if we notice any problems we'd of course contact you first.
We'd love to have you as a customer!
We have 2 large road blocks for Bitbucket. First is a real nice review system with inline comments during a pull request. Is this coming soon? It's an absolute deal breaker for us.
Also the performance/usability seems to be lacking compared to Github. I hope that changes. Although we also use JiraStudio and it's performance is dreadful. And the usability is quite frustrating. So the Atlassian track record is a little worrying for us.
Yes. In fact Github implemented the Git plugin for Mercurial that lets you use Github (or any Git repository) with Mercurial as your client rather than Git.
I guess this shows which DVCS is winning?
The problem I have with git isn't in its syntax. It's in more central decisions with which I disagree fairly strenuously (I am very strongly in favor of indelible history, for example).
But in any VCS you can of course start over. Set the system clock back and check the existing code from another repo into a new one in different chunks making it appear to have been made differently in the first place. There's no way around that other than signing your commits which would work in git as well...
http://google-opensource.blogspot.com/2011/07/announcing-git...
This shows which DVCS is winning.
Why on earth, in the software world, taste / choice diversity is immediately considered as a war?
There is the editors war, DVCS war, OS war, Browsers war.
Let's give peace a chance!