How many applications are left that still use Mercurial? I can only think of two big ones, the JDK and Mozilla's entire code base. Are there still others around? Seems like everyone's moving to Git these days, which is great considering I never did get the hang of Mercurial.
It obviously isn't 'factually' better - that's a matter of opinion not fact.
And in my experience, both Mercurial's model and UI is very over-complicated with far too many concepts. Git has a smaller number of simpler primitives and primitive operations. I think that makes the underlying model of Git better and that's why I prefer it.
Yes, we should.
Remember when GCC had no open source competition? Things have been much better since clang came out.
Or consider openssl since libressl came out. Yes it's possible that codebase improvements would have happened anyways, but having open source competition is great.
I would love a competitor with significant benefits. Git has plenty of warts.
As it stands, it's just a lot easier to use Git everywhere though, just so developers don't have to learn a new tool.
https://pijul.org/ is the only somewhat somewhat interesting alternative I know about, but it's implementation is in alpha territory, and development seems dead.
As one of the authors, I can tell you that Pijul development has never been as alive as today. It isn't public yet for a variety of reasons, but will be very soon.
Google uses a proprietary backend with the primary front end written to look like a clone of the perforce tool p4. The newer frontend that's getting investment is mercurial based. There also exists unofficial/deprecated support for a git frontend.
Not huge but libsdl was one of the ones I ran into recently. (I’ve seen a couple of Subversions too, since I’m visiting a lot of open source projects these days.)
What is it specific that you dont get ? I actually thought hg is conceptually simpler.
And hg to me has always felt BSD like, Git was Linux like. Unfortunately everything with BSD failed to gain any popularity. Including BSD license in itself.
( Yes I know Netflix are using it in their Edge Appliance )
Good choice from moving to Git [0], very risky move on moving to GitHub. If this was just a mirror then that would be fine but it is moving from Mecurial to Git and then the whole project to GitHub.
They should do what Xfce, GNOME and KDE have done and they have self-hosted their own repositories on Gitlab, which GitHub requires the Enterprise Edition for self-hosting. Not really an option, unless you want to pay for this.
The risks outweigh the pros for GitHub as I have said before [1] and will say it again. Self-hosting over 'centralising everything' on GitHub.
I do think it's an important concern, even though I absolutely love Github. Most importantly though, `git` is not centralised, and no service like Github, no matter what it does, can ever stop the decentralisation, roll-your-own-ability, or forkability of open-source software.
So probably it's OK for now for the majority of the community to use MS's platform Github, because other options exist and it's not hard to move to them or create new ones at any time. Github doesn't own our brains, nor can it do any harm to the powerful GNU GPL.
While you are right, there is more than just the code. In general one should be wary for lock-in when sculpting their development processes around the features that GH offers, i.e. the Issue tracker, Projects & Teams, Discussions and not to forget GH Actions. And besides that there is FOMO for many projects to leave GH due to its popularity. Does your contributor base move with you to another platform? Is it as easy to find new contributors, or even to find the project itself?
..which is why I am somewhat convinced that Github single-handedly increased participation in OSS by orders of magnitude.
I never figured out the processes to submit patches in the dark time of sourceforge and mailing lists. Since Github standardized this, I frequently contribute.
I agree with that and I have the same experience however it's important to also recognize the dangerous of the centralization and vendor lock-in not only the convenience.
Hence why running own infrastructure and mirror to Github makes a lot of sense for bigger open-source projects.
For the record, I have the complete opposite experience. It used to be possible to just e-mail someone a description of your code fix, with a diff output inlined or attached. Nowadays, when I try that, people ignore the code you wrote and say “No, please patch is a git patch” (actual quote), or they require a pull request on GitHub. (I don’t have an account on GitHub, and I seriously doubt that I’ll ever get one.)
My experience is that they want even more, an actual pull request. And when you do submit it as a PR, they want you to go back and "rebase" over latest again. For someone thats not so familiar with the process it's intimidating.
I would be more sympathetic to this position if GitHub allowed user-provided domains as CNAMES; and I mean in both directions: redirecting you off github.com to the user's domain name, allowing true federated independence from the centralized platform. Without this feature, the argument is nonsense: you may as well be making the same claim about any other hosting service, as you can almost always pick up your content and put it somewhere... the question is how to update the hundreds, thousands, or even hundreds of thousands of links to your content once you decide to (or are forced to) migrate :/.
As much as I hate that the web, like many memory unsafe languages, permits dangling pointers, I feel like it would be a huge phishing/open redirect/some other web security buzzwords if this happens. Plus, can you even CNAME a specific URL (as opposed to redirecting it)?
I don't understand what "CNAME a specific URL" means. (If you are thinking "can this be done in any reasonable way without GitHub adding the feature", the answer is "no": they would have to provide the feature on their end, to provide the right content given the right hostname, the same way many other companies have over the years, including Medium, which is but one of many possible specific examples I mostly bring up as I hear they recently stopped allowing this and it has correctly made people say others should no longer use the platform due to URL lock-in.)
I'm talking about CNAME, which as I understand lets you do something like "saagarjha.github.com" → "saagarjha.com" but not "github.com/saagarjha" → "saagarjha.com". Of course, GitHub would need to support this on their end, but I don't think the second is possible using CNAMEs, which is what you would really want?
I followed your link, which said that projects can self-host. True. Oracle can self-host if they want to. Should they want to?
I followed your link in that one, which says you should self-host to avoid GitHub-related downtime. So does the next link in the recursive trail, and most of the ones in there. It's true that if you aren't on GitHub, you'll avoid GitHub-related downtime - but how much downtime will your alternative incur, and what is the cost of the staffing needed to reach that point? And what is the downside of being unable to access GitHub briefly for a project like this, such that it becomes worth investing in that staffing?
> I used to help maintain Xfce's svn and then git server. I'm not going to say it was hard, but it was work, and it was work that took time (time that was volunteer free time) away from working on Xfce itself. [...] That was a foolish attitude that took time away from the actual goal, which was making Xfce better.
I will certainly agree that you should not host your primary website on GitHub; there are services that are designed for reliable website hosting. For something like Java, I'd also say you shouldn't host your releases on GitHub. But Oracle Java remains on Oracle's website, and OpenJDK binaries aren't hosted on GitHub - AdoptOpenJDK's website is behind Cloudflare.
I do also think people should have a strategy for moving off their code hosting provider, including making backups of things like issues/pull requests. But that applies even if (perhaps especially if) you self-host, and I don't know anyone who actually does that, regardless of provider. If you're just interested in the code itself, the nice thing about git is that every developer's laptop is an effective backup, so you can put off figuring out a business continuity plan until an actual problem arises.
A few links in (https://news.ycombinator.com/item?id=23102942), you seem to claim that GitHub is insecure because Microsoft's org account was "hacked". It turns out that one account belonging to an MS employee who was a member of that org was broken into https://www.zdnet.com/article/hacker-gains-access-to-a-small... . That risk doesn't seem particularly fundamentally different with self-hosting, since the attack was on the user account, not the service itself.
One link beyond that (https://news.ycombinator.com/item?id=23057769), you point out that you'd need to trust GitHub not to snoop on your private data, which is true, but irrelevant in this context.
Let me be clear - I am not an advocate of moving things to "the cloud" / hosted services for its own sake, and in fact, I believe that most of the time, people are better-served by putting a couple of servers in colo than by using some public cloud service. (My own employer runs an internal GitLab instance and spends a decent bit of staff time on keeping it operational and upgraded, and I think that's a great idea for us and for our needs!) But that's because I believe it's actually better for them to do so. I don't see the argument that people are actually better off running their own git hosting for open-source projects, in general.
Gitlab’s community edition is a frustrating experience.
We created our private instance in 2012 or so, when Gitlab was bot looking for world domination and the entire project was promised to be open source forever, and they were gonna make money off the hosted service and support contracts.
Well, then the VC money hit and now navigating through basic features can be a confusing mess.
So after many years they released merge request reviews to the community edition. This would be great, except you don’t get access to enforcement. So the approval is a purely decorative feature (that would be as easily achieved earlier by simply having any approved hit the button).
To be able to develop any sort of collaborative project you have to install the proprietary version and at that point you’re hardly better off than Github except you’re paying more for less (although I’m not exactly sure of Github’s on prem pricing but the hosted Github is way more bang for the buck than either the hosted or on prem Gitlab). Gitlab also recommends installing the Proprietary edition and using the “free” tier over the community edition so you can upgrade to the paid features, which you cannot on the community edition. So if you don’t want to be blocked in the future you’re installing the proprietary version anyways.
And going with Gitlab you’re also rewarding the scammy bait and switch they pulled some years ago (I’m not sure when this changed because I stopped working with the company I setu it up at, but you can see the archive.org look at their website for the different focus earlier, and the off website messaging was also very different).
I work on OpenJDK. Here are some steps we've taken to not overly depend on GitHub:
1. Issues stay on a self-hosted JIRA.
2. All PRs get an automatically generated patch that's posted to the mailing list, and all comments are two-way mirrored between GH and the mailing list.
3. All links to commits in issues don't point directly at GH but at an indirection through our domain.
4. All bots work on both GH and GitLab
This means that we can move off of GH pretty much instantly if the need arises. But self hosting with GitLab just wouldn't serve our goals. We want speed all around the world, and we don't want to spend resources on administration.
Issues stay on a self-hosted JIRA.
It's really sad as you will have order of magnitude less contributions on jira.
Couldn't you autosynchronize github.com issues to jira ones?
Otherwise, you're hurting the ecosystem as a whole
YEARS ago at a conference I got really mad at Gosling and told him that Java was going to be Open Source one way or another and that they might as well Open Source it now and maybe SUN wouldn't implode.
How would this have prevented Sun from “imploding”?
Wasn’t Sun’s main issue that they were selling extremely expensive hardware and a proprietary OS that were completely overtaken by x86 and Linux?
I remember getting to play with the very expensive hardware they’d handout to startups in the late 90’s and early 00’s. It was good hardware, but it wasn’t so much better than the slightly more buggy and much less costly Linux systems at the time.
According to Larry Ellison, one of the biggest problems that Oracle discovered when they acquired Sun was that sales compensation was based solely on the value of the sale, with no requirement for the deal to make a profit. Their sales team had been merrily selling them to bankruptcy. [1]
Geniuses with tech, but maybe not so good on the business side?
Interesting.
“But then there started to be curious sightings, all around town: Rats, alive and healthy, running around without their tails.
It turned out the hunters would rather amputate a live animal’s tail than take a healthy rat, capable of breeding and creating so many more rats—with those valuable tails—out of commission. There were also reports that some Vietnamese were smuggling foreign rats into the city. And then the final straw: Health inspectors discovered, in the countryside on the outskirts of Hanoi, pop-up farming operations dedicated to breeding rats.”
I'm sorry but first the majority of software companies focus their sales compensation on the contract value (TCV) rather than the profitability. It's not generally the sales teams job to evaluate profitability, that the product/commercial teams job by setting out the lines of discount. The reason is that for most tech companies you want to maximise your market reach.
More importantly, I wouldn't trust a word that Larry Ellison says - particularly when the primary purpose of the article was to boost the Oracle share price by explaining that Sun would be additive to that quarters profits. I'm not saying that Scott McNeally or Jonathan Schwartz were great execs - I have no idea - but I think you have to look at the goal of the article.
Sun's main issue was that they failed to capitalize on all the wonderful tech they had including Java, VirtualBox and Openoffice/StarOffice. Even after open sourcing all of them, they could have kept the company running by marketing to enterprises and offering support.
If they had learned these skills from companies like RH/SUSE/IBM, then Java would have been in much better hands today.
First of all, Oracle and IBM have been part of Java world since the early days with their own Java implementations, and Oracle even jumped on Sun's boat regarding those Java based thin client workstations that were all the rage around 1998.
Secondly, with Sun you would never had gotten AOT, because they saw it as something that 3rd party vendors like Oracle and IBM should care about, they were fully into "JIT or bust", and MaximeVM would have followed the same path as SPOTs, instead of turning into GraalVM.
Didn't Sun open-source Java before Android launched (but after Android had already done a significant amount of implementation internally)? Looks like they open-sourced it in fall 2006. Android was founded in fall 2003 and acquired by Google in summer 2005, but I can't find any public references to it being Java-based from before 2007.
Android is now using OpenJDK and (I assume) not paying anything to Oracle for it. I think they could theoretically have rebased on top of OpenJDK in early 2007 if they expected it to be a serious legal problem, and Sun would have been no better off.
Java has editions and profiles that implement different APIs and features, so Android's subsetting doesn't seem all that different. MIDP had even more missing.
Except those editions have reference documentation that specifies what they provide, across all COMPLIANT implementations.
Android Java is more like cowboy coding, whatever needed to keep Kotlin relevant libraries going on Android.
And to know what Java API is available one needs to crawl Android documentation to track down on which API level they got added into the platform.
The irony is that I am yet to see Android Studio, Gradle and Kotlin running to top of ART/desktop, a JVM free toolchain. Which apparently would be the direction that Google is driving into.
Actually, J2ME was open sourced as well but with one crucial difference: it was GPL v2 but without the classpath exception they used for the regular version.
With the classpath exception, dynamically linking class files is allowed. Normally this would be a form of creating a derived work thus triggering the virality of the license. This is crucial because it meant phone manufacturers could not take the OSS version and be able to ship it without having to OSS all their proprietary stuff linked against it. Sun was making a bit of money licensing J2ME to just about all phone manufacturers. The Gnu classpath was unusable for mobile phone manufacturers for the same reason: it would expose them to its viral clauses.
The Google & Oracle conflict is related to this because when Google bought Android (in 2004?), they ended up using Apache Harmony, which was a newly created project backed by IBM with an Apache licensed implementation of the Java standard library. It allowed Google to opt out of Sun's restrictive licensing deals, dodge licensing issues with gnu licensed code, and at the same time ignore the design by committee style API design that Sun insisted on with the rest of the industry.
Basically, it enabled them to run the whole of Java as they had their own vm and standard library implementation. Given improvements in mobile hardware, this was an obvious thing to want to do technically by that time. After Android shipped, there was little to no point at all to J2ME and it quickly became a thing of the past.
So, when Oracle bought Sun in 2010, all of that had already happened half a decade earlier. IBM pulled the plug on Harmony shortly after the acquisition and Google eventually incorporated much of Openjdk into Android to replace their Apache Harmony based implementation and also to modernize the code base. This is still licensed with the classpath exception; so they can do this.
Except the little fact that Android Java has become Google's J++, forking the Java community, while creating lots of pain for any Java library author that would like to support Android as deployment target.
Google had the opportunity to fix up their screw up by buying Sun, which they didn't, most likely hoping that Sun would sink silently, and they would get away with their little power games and industrial torpedoes.
Unfortunately for them, and fortunately for us Java devs, as I wouldn't like the Android architects to design Java, Oracle did not thought the same way.
Open JDK has been there since 2007, large part of Java tools and libraries are under open source license, JCP has been advocating open development since 1998 so I call this BS.
Why would you argue that point with him? He always wanted Java (and Solaris) to be open source, it was the Sun execs who took more than a decade to finally agree.
I don't exactly know why you are being downvoted, you are absolutely right, albeit a bit snarky.
Microsoft is currently embracing open source and people wonder why that is. Their history around FOSS is worrying and some question if it's part of "Embrace, Extend, Extinguish".
Plus it's very ironic that Microsoft is now the hoster of Java's source code after their failed proprietary Java implementation (J++) which eventually lead to the creation of C# after being sued by Sun.
J++ did not fail, it was the first language designed by Anders after joining Microsoft and had a sane FFI, which became P/Invoke and their Forms framework was the basis of Windows Forms.
So yeah, they failed to win the court process if that is what you mean.
Also something that many seem to forget, .NET was also released with J#.
Another fun fact, JNI is hard by design as means to promote WORA, and Project Panama that is supposed to replace it has several ideas similar to P/Invoke.
Finally many that celebrate Sun's victory over Microsoft regarding J++, are too eager to pick Android Java side nowadays.
A minor point: while MS has been embracing OSS, they've never been in support of software freedoms ("libre") because it's fundamentally incompatible with their business models. Yes, most OSS software is also libre, but MS doesn't care about that.
Neither do many FOSS developers nowadays regardless of the dream, as supermarkets don't take pull requests so they end up adopting dual licenses or putting the golden eggs behind Server walls.
Someone in the 2000s: "I bet that in about a decade Java will be owned by Oracle and they will host the source code on a Microsoft website using Linux and git.
It bothers me that they repeatedly write about a migration "from Mercurial to GitHub", rather than "from Mercurial to Git". It seems to imply that GitHub hosting is the only way to run Git.
It's perfectly fine to say that they are moving to GitHub hosting, but not to put it on the same level as Mercurial: Mercurial and Git are applications/protocols, while GitHub is a hosting service. You should compare application with application and hosting service with hosting service.
I'm not sure what's objectionable about that blog post? It describes a common scenario for using the compatibility layer (and indeed the main motivation for creating it).
Especially early on when the compatibility layer was only fully tested with a specific version of Ubuntu.
I would think at this point most developers should know that there are services like GitLab and BitBucket, and thus even if they are not totally aware of how Git works as a protocol they should be aware that Git is not directly tied to GitHub.
Its fun for me to say this, but it just goes to show the kind of people behind the project today, i mean, did you see the explosion in versioning ? OJDK/ORACLE duo slowly feeding the hype machine by carefully making moves that all the players look good. You say github, i see a very careful type of microsoft pitch.
That all said ... well good on them, its about time.
Very true and the search engines are to be blamed as well.
Recently, I was searching for a Git - fork project (i.e. a project forked from git itself) which allowed separate machine based accounts for Git branches. It was quite famous, I had used it about 4 years back and I don't remember its name now.
Now, this is the worst case scenario for the search engines -
• 'git fork project' would bring numerous github forked projects.
• 'git original source' would bring the mirror of git in github, but then again there are hundreds of fork.
After, lot of time spent on this in vain, I gave up.
UPDATE:
While writing this comment I remembered the USP of that project was 'Branch specific permissions', so I gave a fresh attempt at finding it and I did via SO! It's Gitolite[1].
Yep, I tried Github as part of the query. Anyways, even without 'GitHub' almost all front page results are from there and that's one of the point I'm trying to make.
You can also exclude results from the site completely with -site:github.com, though you're still left with the problem that 'git fork' and variants won't really bring up results that are forks of git, but results that are about forking in git.
Ultimately, in this case only recalling the USP or a similarly unique phrase was ever going to help you find the result you were looking for.
Yes, this bothers me too. The extra features that Github offers on top of Git are generally referred to as a 'forge' [0].
And talking about forges I hope we will look beyond just Github and consider all of them (gitlab, gitea, sourcehut, gogs, pagure, gitern, etc.) and focus on their interoperability!
Just mentioned in another comment, but ForgeFed [1] could be the solution to achieve this, creating a federation of forges where it doesn't matter which software one prefers.
I get that but I think by saying "Github" instead of "git" one is emphasizing the social and collaborative aspects of Github over plain git. My 2 cents anyway.
That would make it even more wrong, since it seems from the JEPs that, at least for the time being, they're only using GitHub as hosting service. No wikis, PRs, issues and so on.
Project Skara appears to consider this a two step process [1]:
> The goal of this Project is to investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties.
> Two JEPs are planned for this investigation, first JEP 357: Migrate from Mercurial to Git [2] and second JEP 369: Migrate to GitHub. . [3]
I do enjoy and agree with the pedantry of your point, but it's difficult to accept that, like many people, they _are_ moving to GitHub, and not Git.
GitHub is as much a tool here as Git itself.
Unfortunate really, as Git should be the panacea of distributed systems, open source. Instead we took that, centralised it all on a single big host, and became dependent on its proprietary features.
Still, these systems come and go. Remember SourceForge anyone?
But what probably differs today is that these modern services seem so much more complex they have an increasing gravity/lock in effect.
You can easily mirror your repository on Gitlab or elsewhere and Gitlab even automates that for you.
And all developers on a project have a backup on their local computer. It might not track the master/main HEAD from Github, but in the event of a disaster you still have backups to recover from.
The nature of git's descentralized nature is misunderstood and I fear the misunderstanding comes from people that did not work with CVS/Subversion.
In any case you still need a source of truth from which releases are cut. And Github has been damned convenient to use as one and you can easily take your git repo and move elsewhere if you want to.
Sure, you can't migrate the links, the project's stars, etc, but that's not part of git. On the bright side, given you can mirror the code, you can keep the Github repo as read-only, which afaik is what the Linux kernel has done.
can gitlab migrate issues? I know github allows you to export them via the API without too much difficulty, but there isn't too many tools that allow you to manage them once you've done that, from what I've found. there's some abandoned viewer projects, but that's not actually a replacement if you want to keep working on the project
It doesn't matter if it can be retrieved by the API or not from a user's perspective.
Merge requests and comments are no longer authored by the correct user, because there's no user mapping - everything ends up getting authored by the user who performed the import.
Inline review comments on MRs appear to be lost or mangled.
Review summary comments on MRs appear to be lost or mangled.
Dates on MRs are lost. Dates on comments are lost.
Don't worry, I do understand Git, and I think you've completely missed the point I was making and thus fallen for the exact trap that I'm pointing out :)
The huge importance of all that data "that's not part of Git", and the workflow and skill set around it.
Add to that a growing body of developers who don't actually know Git, but do know how to press the button in GitHub.
I don't make any claim for the particular JDK project here, but people _are_ migrating to GitHub, not Git.
Yes, as the GP this is my original point. I completely agree that they are moving to GitHub. I don't think there are referentially false sentences in the OP, it's more a remark about the language (which is not a secondary aspect).
It's not a pedantic point. Since the relationship between the references is wrong (SCM <> hosting service), one can't do an analysis.
Putting it in those terms, questions like the storage requirements of an SCM can't be answered (because GH is a hosting service) and usability of a hosting service can't be answered either (because Mercurial is an SCM). Ultimately, it doesn't allow the fundamental question to be answered - was it a matter of SCM, of hosting service, or both?
As a matter of fact, the article is imprecise/confusing, as it partly mixes issues that were originally separate (although later it expands on this).
What's wrong with you people downvoting answers that merely give an opposing view in a non-condescending way. Jeez, this site should remove those buttons.
I should have put a smiley face on the pedantry comment...
I get what you're saying, and if this project in question just wants a "hosting service" and to never touch any of its features, then ok.
But the broader point is that these are not hosting services; they're full-on toolsets and workflows that people are migrating to (or towards, in this case).
Well, if they are consciously moving to use the Pull Request, Issue tracker, Actions, Wiki, and other features of GitHub, and incidentally Git as part of the package, then I'd say that yes, they _are_ moving to GitHub, and not just Git.
Edit: I was specifically thinking on this main point they mentioned: "Programmatic APIs to enable process assistance and automation of review and processes", which to me means PR and Actions. I was just assuming that they will probably also use the Issues feature too.
> In order to prevent the Skara tooling from depending upon a particular provider's API, support for multiple external providers has been a strict requirement from the beginning. All of the tooling is also required to work with the open-source GitLab Community Edition (GitLab CE).
I wonder why they didn't pick GitLab though. They just mention it as an alternative, but there's not a single word on why they preferred one over the other.
Because "Github is where it's at!". They're looking for an instantly-large community with built in support. Everyone has a Github account, but not everyone has a Gitlab account. Yes it's easy to get a Gitlab account for free, but that's still a barrier at the moment.
I agree. I don't think your point is pedantic, although I think calling GitHub a "hosting service" downplays some major features that GitHub has. For me the big one is code reviews (via pull requests), but it also has GitHub Issues and GitHub Actions, amongst other things.
So when someone says they're migrating "from Mercurial to GitHub", I'm left wondering: what were they previously using for code reviews, issue tracking, etc?
From the article:
> OpenJDK has used the Mercurial source code management solution since 2008 to store source code and conduct code reviews
This doesn't make sense. Mercurial doesn't provide a code review feature, and neither does Git. So what do they currently use for code reviews?
I had to dig in to the site a bit, but the workflow is described in https://openjdk.java.net/guide/codeReview.html. It looks like they use a (Korn!) shell script called "webrev" that will "generate a set of web pages to display the differences", and they then scp over the static html files to a shared public web server. Here's an example I pulled out of their Atom feed: https://cr.openjdk.java.net/~pbansal/8249548/webrev00/. It's not really clear to me how they comment on each others' diffs, but I guess this must be done out-of-band (maybe via email, chat or walking over to their desk).
It really feels like Git is a relatively small part of the migration. Mercurial and Git support more-or-less the same set of features, and neither one is really much better than the other (tbh I like Mercurial slightly better). Moving to GitHub as a code review tool (and possibly other things too) is going to have a much larger impact on the developer workflow than the version control tool.
They are advertising for GitHub, I still don't know why people feel the need to use Github for well known projects other than the "social" aspect of GitHub. It would be interesting to see if it would be possible to extract the "social" aspect out GitHub and allow people to host git with a distributed social model (i.e. you host your own git on your own decentralized server but your social account and associated comments/metadata are all centralized.)
The problem with consolidating everything on GitHub is that, to me, you're selling your user's and contributor's clicks. Moreover, GitHub blocks indie search crawlers, and as such is just a content silo. Now F/OSS software licenses, at least of the reciprocal kind, make very much a political statement by their license choice, willingly or not, that is questioned by using GitHub (or any other gateway cashing in on user engagement data) as project host. The really ugly and depressing thing is that F/OSS projects seek networking effects on GitHub, turning a super-powerful and easy dSCM into a centralized hub in a heartbeat; to me, they kindof devalue their own (massive) work by trading it for only the attention value it gets on GitHub, and contributing to the oligopolistic web. Hosting GPL software on GitHub is like sticking fingers in your ears, dogmatically adhering to a licensing taxonomy of yesteryear, while refusing to face today's problems. I'm not sure what incentive to go to GitHub is there for a project with a defacto closed group of developers that's been in the works for years or decades already; it's not like the project seeks indie contributors anyway. Might be better to support https://codeberg.org/ .
I agree with all of the above. - The incentive for a mature project with some rogue corporate developers that are no longer idealistic is this:
1) Moving a project to GitHub ingratiates them with their puppet masters and generates a lot of billable hours.
2) Once on GitHub, these "developers" keep complicating the commit procedures so that even doc fixes look like a lot of work. More billable hours.
3) GitHub makes it easy to generate green squares for review actions. Merging a PR that another idealistic person put a lot of work in just requires a click. Half of the credit goes to the core developer. It looks as if the core "developer" is doing a lot of work.
4) If you apply the above methods, you will have green GitHub statistics and increase your market value.
pg has written about similar tactics in an essay where he explains why developers love Java. It is sad that open source is now "embraced" to such an extent that the same tactics apply there.
The idealistic developers are not political enough to prevent the bureaucrats from taking over. Also, they do not have time because they are actually writing code.
oh wow, this is just a straight up github clone. I actually kinda like that, it's an interface pretty much everyone is used to, and it's good too. Maybe they should change the color scheme or something a little though, so you don't forget you're not just on github, cause if I scrolled down and reopened the tab, I would definitely think I was on github
Codeberg is just a hosted Gitea instance (click help in the menu bar and it takes you to the Gitea docs).
Gitea is wonderful and definitely something you can host yourself for friends and family. I've even enabled KaTeX rendering in comments/issues/Markdown files on mine, which is something GitHub probably won't do anytime soon.
oh huh, I had heard of gitea but I didn't know it was so similar to github. I may actually set up an instance for myself then, I'm using github issues for some personal stuff that isn't collaborative
It is also much faster than GitHub based on a bit of browsing i just did. Project pages, etc opened almost instantly whereas on GitHub everything takes a while to open.
they seem pretty much identical on my connection. Basically everything loads in under a second. I thinks it's probably just your connection/where you live/the path between them and you.
What is Codeberg's selling point over Gitea? I see they contribute to the community every so often, but is it just a hosted instance of Gitea? Or is there some other value-add on top of Gitea? Just curious why you wouldn't recommend donating to the Gitea community directly.
Can't say whether it's "just" a hosted version of Gitea (or gitlab), but the point is, in fact, that it's hosted, doesn't track you, and can give your project a permanent URL that isn't unfamiliar to a crowd "educated" and networked to find everything on github.
Now a better solution still would be to self-host on a proper project home page.
Codeberg looks like it’s just a hosted instance of Gitea, so it’s the same comparison between sourcehut/Gitea (which is largely the same comparison between sourcehut/GitLab/GitHub, etc)
Having worked with multiple Mercurial repositories managed by a custom tool which is now also being converted to Git, I can confirm that the smart choice for a new developer is to choose Git.
It’s no longer “Choose Git or Mercurial?” that is the topic, but instead it is which Git branching model to choose.
For the usual VCS operations such as adding files, committing and pushing i’d say they are quite similar.
If you’re doing really complicated merges (which you should avoid anyway), then yes Mercurial is better in my opinion.
But given the prevalence of Git, e.g. it is much easier to find a new dev with Git experience and also much easier to Google a Git problem, it seems only natural that more and more Mercurial repos will be converted to Git.
138 comments
[ 2.9 ms ] story [ 195 ms ] threadI might worry about a monoculture around a hosted service like github, but not git itself.
It obviously isn't 'factually' better - that's a matter of opinion not fact.
And in my experience, both Mercurial's model and UI is very over-complicated with far too many concepts. Git has a smaller number of simpler primitives and primitive operations. I think that makes the underlying model of Git better and that's why I prefer it.
Or consider openssl since libressl came out. Yes it's possible that codebase improvements would have happened anyways, but having open source competition is great.
As it stands, it's just a lot easier to use Git everywhere though, just so developers don't have to learn a new tool.
https://pijul.org/ is the only somewhat somewhat interesting alternative I know about, but it's implementation is in alpha territory, and development seems dead.
https://github.com/facebookexperimental/eden
Previous discussion https://news.ycombinator.com/item?id=23124095
What is it specific that you dont get ? I actually thought hg is conceptually simpler.
And hg to me has always felt BSD like, Git was Linux like. Unfortunately everything with BSD failed to gain any popularity. Including BSD license in itself. ( Yes I know Netflix are using it in their Edge Appliance )
Coming from git to hg, it was a step back in time to branches that can’t ever actually be deleted and bookmarks are... not obvious.
Can you actually create two bookmarks on your current commit and then move forward on just one? who knows? I never figured it out.
Good choice from moving to Git [0], very risky move on moving to GitHub. If this was just a mirror then that would be fine but it is moving from Mecurial to Git and then the whole project to GitHub.
They should do what Xfce, GNOME and KDE have done and they have self-hosted their own repositories on Gitlab, which GitHub requires the Enterprise Edition for self-hosting. Not really an option, unless you want to pay for this.
The risks outweigh the pros for GitHub as I have said before [1] and will say it again. Self-hosting over 'centralising everything' on GitHub.
[0] https://openjdk.java.net/jeps/357
[1] https://news.ycombinator.com/item?id=23849565
So probably it's OK for now for the majority of the community to use MS's platform Github, because other options exist and it's not hard to move to them or create new ones at any time. Github doesn't own our brains, nor can it do any harm to the powerful GNU GPL.
I never figured out the processes to submit patches in the dark time of sourceforge and mailing lists. Since Github standardized this, I frequently contribute.
Hence why running own infrastructure and mirror to Github makes a lot of sense for bigger open-source projects.
I hope for more decentralization of forges in the future in a more open market, and I have my eye on ForgeFed as means to achieve that.
https://forgefed.peers.community
Not the most important thing... Basically all project I work on still relies on a "central peer" ...
I followed your link, which said that projects can self-host. True. Oracle can self-host if they want to. Should they want to?
I followed your link in that one, which says you should self-host to avoid GitHub-related downtime. So does the next link in the recursive trail, and most of the ones in there. It's true that if you aren't on GitHub, you'll avoid GitHub-related downtime - but how much downtime will your alternative incur, and what is the cost of the staffing needed to reach that point? And what is the downside of being unable to access GitHub briefly for a project like this, such that it becomes worth investing in that staffing?
There's this reply to your comment that I see you didn't reply to: https://news.ycombinator.com/item?id=23818307
> I used to help maintain Xfce's svn and then git server. I'm not going to say it was hard, but it was work, and it was work that took time (time that was volunteer free time) away from working on Xfce itself. [...] That was a foolish attitude that took time away from the actual goal, which was making Xfce better.
I will certainly agree that you should not host your primary website on GitHub; there are services that are designed for reliable website hosting. For something like Java, I'd also say you shouldn't host your releases on GitHub. But Oracle Java remains on Oracle's website, and OpenJDK binaries aren't hosted on GitHub - AdoptOpenJDK's website is behind Cloudflare.
I do also think people should have a strategy for moving off their code hosting provider, including making backups of things like issues/pull requests. But that applies even if (perhaps especially if) you self-host, and I don't know anyone who actually does that, regardless of provider. If you're just interested in the code itself, the nice thing about git is that every developer's laptop is an effective backup, so you can put off figuring out a business continuity plan until an actual problem arises.
A few links in (https://news.ycombinator.com/item?id=23102942), you seem to claim that GitHub is insecure because Microsoft's org account was "hacked". It turns out that one account belonging to an MS employee who was a member of that org was broken into https://www.zdnet.com/article/hacker-gains-access-to-a-small... . That risk doesn't seem particularly fundamentally different with self-hosting, since the attack was on the user account, not the service itself.
One link beyond that (https://news.ycombinator.com/item?id=23057769), you point out that you'd need to trust GitHub not to snoop on your private data, which is true, but irrelevant in this context.
Let me be clear - I am not an advocate of moving things to "the cloud" / hosted services for its own sake, and in fact, I believe that most of the time, people are better-served by putting a couple of servers in colo than by using some public cloud service. (My own employer runs an internal GitLab instance and spends a decent bit of staff time on keeping it operational and upgraded, and I think that's a great idea for us and for our needs!) But that's because I believe it's actually better for them to do so. I don't see the argument that people are actually better off running their own git hosting for open-source projects, in general.
We created our private instance in 2012 or so, when Gitlab was bot looking for world domination and the entire project was promised to be open source forever, and they were gonna make money off the hosted service and support contracts.
Well, then the VC money hit and now navigating through basic features can be a confusing mess.
So after many years they released merge request reviews to the community edition. This would be great, except you don’t get access to enforcement. So the approval is a purely decorative feature (that would be as easily achieved earlier by simply having any approved hit the button).
To be able to develop any sort of collaborative project you have to install the proprietary version and at that point you’re hardly better off than Github except you’re paying more for less (although I’m not exactly sure of Github’s on prem pricing but the hosted Github is way more bang for the buck than either the hosted or on prem Gitlab). Gitlab also recommends installing the Proprietary edition and using the “free” tier over the community edition so you can upgrade to the paid features, which you cannot on the community edition. So if you don’t want to be blocked in the future you’re installing the proprietary version anyways.
And going with Gitlab you’re also rewarding the scammy bait and switch they pulled some years ago (I’m not sure when this changed because I stopped working with the company I setu it up at, but you can see the archive.org look at their website for the different focus earlier, and the off website messaging was also very different).
1. Issues stay on a self-hosted JIRA.
2. All PRs get an automatically generated patch that's posted to the mailing list, and all comments are two-way mirrored between GH and the mailing list.
3. All links to commits in issues don't point directly at GH but at an indirection through our domain.
4. All bots work on both GH and GitLab
This means that we can move off of GH pretty much instantly if the need arises. But self hosting with GitLab just wouldn't serve our goals. We want speed all around the world, and we don't want to spend resources on administration.
If your project is setup in a way to just git push to another remote and then you're done, then I think it's fine to use Github.
Well... I was right.
Wasn’t Sun’s main issue that they were selling extremely expensive hardware and a proprietary OS that were completely overtaken by x86 and Linux?
I remember getting to play with the very expensive hardware they’d handout to startups in the late 90’s and early 00’s. It was good hardware, but it wasn’t so much better than the slightly more buggy and much less costly Linux systems at the time.
Geniuses with tech, but maybe not so good on the business side?
https://www.barrons.com/articles/BL-TB-24039
Also a good read: https://www.atlasobscura.com/articles/hanoi-rat-massacre-190...
It turned out the hunters would rather amputate a live animal’s tail than take a healthy rat, capable of breeding and creating so many more rats—with those valuable tails—out of commission. There were also reports that some Vietnamese were smuggling foreign rats into the city. And then the final straw: Health inspectors discovered, in the countryside on the outskirts of Hanoi, pop-up farming operations dedicated to breeding rats.”
More importantly, I wouldn't trust a word that Larry Ellison says - particularly when the primary purpose of the article was to boost the Oracle share price by explaining that Sun would be additive to that quarters profits. I'm not saying that Scott McNeally or Jonathan Schwartz were great execs - I have no idea - but I think you have to look at the goal of the article.
If they had learned these skills from companies like RH/SUSE/IBM, then Java would have been in much better hands today.
Secondly, with Sun you would never had gotten AOT, because they saw it as something that 3rd party vendors like Oracle and IBM should care about, they were fully into "JIT or bust", and MaximeVM would have followed the same path as SPOTs, instead of turning into GraalVM.
So if you have any problem with Oracle, thank Google in first place.
So I had to deal with Solaris, Aix, HP-UX, and Windows NT/2000.
We also rented servers for in-house development.
Their rates were just like everyone else on the Fortune 500 world.
Android is now using OpenJDK and (I assume) not paying anything to Oracle for it. I think they could theoretically have rebased on top of OpenJDK in early 2007 if they expected it to be a serious legal problem, and Sun would have been no better off.
Android is not using OpenJDK as such, that is Google's marketing.
What Google is doing is cherry picking code from OpenJDK and adapting it to Android.
What they care about is keeping Kotlin's FFI to Java libraries relevant.
In Android 11 there are a couple of Java APIs all the way to 13, that they again cherry picked from.
https://android-developers.googleblog.com/2020/07/11-weeks-o...
It is quite easy to track from their Gerrit which stuff gets copied from OpenJDK and what keeps being ignored.
They always end their Java update announcements asking for what APIs are relevant, while for anyone else it is clear that only 100% matters.
And we aren't even getting into language features or JVM bytecodes that don't have parity with ART ones.
Android Java is Google's J++.
Also for selling Kotlin they always use Java 7/8 code style when comparing against Kotlin code.
Android Java is more like cowboy coding, whatever needed to keep Kotlin relevant libraries going on Android.
And to know what Java API is available one needs to crawl Android documentation to track down on which API level they got added into the platform.
The irony is that I am yet to see Android Studio, Gradle and Kotlin running to top of ART/desktop, a JVM free toolchain. Which apparently would be the direction that Google is driving into.
With the classpath exception, dynamically linking class files is allowed. Normally this would be a form of creating a derived work thus triggering the virality of the license. This is crucial because it meant phone manufacturers could not take the OSS version and be able to ship it without having to OSS all their proprietary stuff linked against it. Sun was making a bit of money licensing J2ME to just about all phone manufacturers. The Gnu classpath was unusable for mobile phone manufacturers for the same reason: it would expose them to its viral clauses.
The Google & Oracle conflict is related to this because when Google bought Android (in 2004?), they ended up using Apache Harmony, which was a newly created project backed by IBM with an Apache licensed implementation of the Java standard library. It allowed Google to opt out of Sun's restrictive licensing deals, dodge licensing issues with gnu licensed code, and at the same time ignore the design by committee style API design that Sun insisted on with the rest of the industry.
Basically, it enabled them to run the whole of Java as they had their own vm and standard library implementation. Given improvements in mobile hardware, this was an obvious thing to want to do technically by that time. After Android shipped, there was little to no point at all to J2ME and it quickly became a thing of the past.
So, when Oracle bought Sun in 2010, all of that had already happened half a decade earlier. IBM pulled the plug on Harmony shortly after the acquisition and Google eventually incorporated much of Openjdk into Android to replace their Apache Harmony based implementation and also to modernize the code base. This is still licensed with the classpath exception; so they can do this.
Google had the opportunity to fix up their screw up by buying Sun, which they didn't, most likely hoping that Sun would sink silently, and they would get away with their little power games and industrial torpedoes.
Unfortunately for them, and fortunately for us Java devs, as I wouldn't like the Android architects to design Java, Oracle did not thought the same way.
Microsoft is currently embracing open source and people wonder why that is. Their history around FOSS is worrying and some question if it's part of "Embrace, Extend, Extinguish".
Plus it's very ironic that Microsoft is now the hoster of Java's source code after their failed proprietary Java implementation (J++) which eventually lead to the creation of C# after being sued by Sun.
So yeah, they failed to win the court process if that is what you mean.
Also something that many seem to forget, .NET was also released with J#.
Another fun fact, JNI is hard by design as means to promote WORA, and Project Panama that is supposed to replace it has several ideas similar to P/Invoke.
Finally many that celebrate Sun's victory over Microsoft regarding J++, are too eager to pick Android Java side nowadays.
Me: Hahahaha, yeah, sure…
And the VSCode plugins are developed in cooperation with Red-Hat.
[1] https://adtmag.com/articles/2019/11/06/microsoft-openjdk.asp...
It's perfectly fine to say that they are moving to GitHub hosting, but not to put it on the same level as Mercurial: Mercurial and Git are applications/protocols, while GitHub is a hosting service. You should compare application with application and hosting service with hosting service.
Just like we can discuss all day about POSIX, UNIX and various implementations of them, while most people would relate to Ubuntu.
It's pretty bothering that most people equate a distributed open-source code versioning system with a centralized Microsoft service, isn't it?
Excluding the contributors to such small projects as KDE, Gnome, Freedesktop, Debian, Arch Linux, Drupal all of which are self hosting Gitlab.
https://blogs.windows.com/windowsdeveloper/2016/03/30/run-ba...
Especially early on when the compatibility layer was only fully tested with a specific version of Ubuntu.
I would think at this point most developers should know that there are services like GitLab and BitBucket, and thus even if they are not totally aware of how Git works as a protocol they should be aware that Git is not directly tied to GitHub.
That all said ... well good on them, its about time.
Recently, I was searching for a Git - fork project (i.e. a project forked from git itself) which allowed separate machine based accounts for Git branches. It was quite famous, I had used it about 4 years back and I don't remember its name now.
Now, this is the worst case scenario for the search engines -
• 'git fork project' would bring numerous github forked projects.
• 'git original source' would bring the mirror of git in github, but then again there are hundreds of fork.
After, lot of time spent on this in vain, I gave up.
UPDATE: While writing this comment I remembered the USP of that project was 'Branch specific permissions', so I gave a fresh attempt at finding it and I did via SO! It's Gitolite[1].
[1]https://github.com/sitaramc/gitolite
Ultimately, in this case only recalling the USP or a similarly unique phrase was ever going to help you find the result you were looking for.
And talking about forges I hope we will look beyond just Github and consider all of them (gitlab, gitea, sourcehut, gogs, pagure, gitern, etc.) and focus on their interoperability!
Just mentioned in another comment, but ForgeFed [1] could be the solution to achieve this, creating a federation of forges where it doesn't matter which software one prefers.
[0] https://en.wikipedia.org/wiki/Forge_(software)
[1] https://forgefed.peers.community
For more detailed information, the OpenJDK mailing lists archive is a good source.
> The goal of this Project is to investigate alternative SCM and code review options for the JDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties.
> Two JEPs are planned for this investigation, first JEP 357: Migrate from Mercurial to Git [2] and second JEP 369: Migrate to GitHub. . [3]
[1] https://openjdk.java.net/projects/skara/
[2] https://openjdk.java.net/jeps/357
[3] https://openjdk.java.net/jeps/369
GitHub is as much a tool here as Git itself.
Unfortunate really, as Git should be the panacea of distributed systems, open source. Instead we took that, centralised it all on a single big host, and became dependent on its proprietary features.
Still, these systems come and go. Remember SourceForge anyone?
But what probably differs today is that these modern services seem so much more complex they have an increasing gravity/lock in effect.
And all developers on a project have a backup on their local computer. It might not track the master/main HEAD from Github, but in the event of a disaster you still have backups to recover from.
The nature of git's descentralized nature is misunderstood and I fear the misunderstanding comes from people that did not work with CVS/Subversion.
In any case you still need a source of truth from which releases are cut. And Github has been damned convenient to use as one and you can easily take your git repo and move elsewhere if you want to.
Sure, you can't migrate the links, the project's stars, etc, but that's not part of git. On the bright side, given you can mirror the code, you can keep the Github repo as read-only, which afaik is what the Linux kernel has done.
Merge requests and comments are no longer authored by the correct user, because there's no user mapping - everything ends up getting authored by the user who performed the import.
Inline review comments on MRs appear to be lost or mangled.
Review summary comments on MRs appear to be lost or mangled.
Dates on MRs are lost. Dates on comments are lost.
The huge importance of all that data "that's not part of Git", and the workflow and skill set around it.
Add to that a growing body of developers who don't actually know Git, but do know how to press the button in GitHub.
I don't make any claim for the particular JDK project here, but people _are_ migrating to GitHub, not Git.
Putting it in those terms, questions like the storage requirements of an SCM can't be answered (because GH is a hosting service) and usability of a hosting service can't be answered either (because Mercurial is an SCM). Ultimately, it doesn't allow the fundamental question to be answered - was it a matter of SCM, of hosting service, or both?
As a matter of fact, the article is imprecise/confusing, as it partly mixes issues that were originally separate (although later it expands on this).
See the two separate JEPs:
- [JEP 357: Migrate from Mercurial to Git](https://openjdk.java.net/jeps/357)
- [JEP 369: Migrate to GitHub](https://openjdk.java.net/jeps/369)
Based on a quick reading, the main driver has been the SCM.
I get what you're saying, and if this project in question just wants a "hosting service" and to never touch any of its features, then ok.
But the broader point is that these are not hosting services; they're full-on toolsets and workflows that people are migrating to (or towards, in this case).
Edit: I was specifically thinking on this main point they mentioned: "Programmatic APIs to enable process assistance and automation of review and processes", which to me means PR and Actions. I was just assuming that they will probably also use the Issues feature too.
- Migrate from Mercurial to Git - https://openjdk.java.net/jeps/357
- Migrate to GitHub - https://openjdk.java.net/jeps/369
And also in JEP 369 at the and there is:
> In order to prevent the Skara tooling from depending upon a particular provider's API, support for multiple external providers has been a strict requirement from the beginning. All of the tooling is also required to work with the open-source GitLab Community Edition (GitLab CE).
So when someone says they're migrating "from Mercurial to GitHub", I'm left wondering: what were they previously using for code reviews, issue tracking, etc?
From the article:
> OpenJDK has used the Mercurial source code management solution since 2008 to store source code and conduct code reviews
This doesn't make sense. Mercurial doesn't provide a code review feature, and neither does Git. So what do they currently use for code reviews?
I had to dig in to the site a bit, but the workflow is described in https://openjdk.java.net/guide/codeReview.html. It looks like they use a (Korn!) shell script called "webrev" that will "generate a set of web pages to display the differences", and they then scp over the static html files to a shared public web server. Here's an example I pulled out of their Atom feed: https://cr.openjdk.java.net/~pbansal/8249548/webrev00/. It's not really clear to me how they comment on each others' diffs, but I guess this must be done out-of-band (maybe via email, chat or walking over to their desk).
It really feels like Git is a relatively small part of the migration. Mercurial and Git support more-or-less the same set of features, and neither one is really much better than the other (tbh I like Mercurial slightly better). Moving to GitHub as a code review tool (and possibly other things too) is going to have a much larger impact on the developer workflow than the version control tool.
The first time I heard about git and github in 2008 I thought this.
1) Moving a project to GitHub ingratiates them with their puppet masters and generates a lot of billable hours.
2) Once on GitHub, these "developers" keep complicating the commit procedures so that even doc fixes look like a lot of work. More billable hours.
3) GitHub makes it easy to generate green squares for review actions. Merging a PR that another idealistic person put a lot of work in just requires a click. Half of the credit goes to the core developer. It looks as if the core "developer" is doing a lot of work.
4) If you apply the above methods, you will have green GitHub statistics and increase your market value.
pg has written about similar tactics in an essay where he explains why developers love Java. It is sad that open source is now "embraced" to such an extent that the same tactics apply there.
The idealistic developers are not political enough to prevent the bureaucrats from taking over. Also, they do not have time because they are actually writing code.
Gitea is wonderful and definitely something you can host yourself for friends and family. I've even enabled KaTeX rendering in comments/issues/Markdown files on mine, which is something GitHub probably won't do anytime soon.
I'd definitely check it out.
Now a better solution still would be to self-host on a proper project home page.
Do they have a deal with Google/Bing? Any details about this crawler block?
It’s no longer “Choose Git or Mercurial?” that is the topic, but instead it is which Git branching model to choose.
If you’re doing really complicated merges (which you should avoid anyway), then yes Mercurial is better in my opinion.
But given the prevalence of Git, e.g. it is much easier to find a new dev with Git experience and also much easier to Google a Git problem, it seems only natural that more and more Mercurial repos will be converted to Git.