Let's make sure GitHub doesn't become the only option(blog.edwardloveall.com)
blog.edwardloveall.com
Let's make sure GitHub doesn't become the only option
https://blog.edwardloveall.com/lets-make-sure-github-doesnt-become-the-only-option
308 comments
Git is also FOSS and is not owned by Microsoft / Github. Using git doesn't really "give" Github anything other than a bit of convenience and brand linkage. If the industry wanted to adopt a git replacement I suppose that Github's use of git could be a hinderance, but honestly the coupling is pretty loose.
Also, I worked in consulting for a few years and while Github was common, so was Azure devops (ironically also Microsoft, though) and one project used BitKeeper. Github might be dominant, but is very far from a "monopoly" in my opinion (I don't know if anyone used that word but if that's not the concern then what's the big deal?)
Also, I worked in consulting for a few years and while Github was common, so was Azure devops (ironically also Microsoft, though) and one project used BitKeeper. Github might be dominant, but is very far from a "monopoly" in my opinion (I don't know if anyone used that word but if that's not the concern then what's the big deal?)
Yes, my experience is that Github isn't actually universal. I've yet to work for a company that uses it, personally. My only interaction with Github is in the hobbyist realm when I want code from an OSS project that is hosted there.
This has been my experience too. I think of Github as more like a social media platform that incorporates git as a convenient feature. Large corps use it as a marketing/PR forum and regular people use it to connect to other people interested in programming.
But what software are large corps use then? I work at a fairly large coorp (>650000 employees) and they are indeed using Github Enterprise (and some other solutions like Bitbucket data center). I'm would be quite surprised if they really only use software like Github for public things.
Azure DevOps is in a weird zombie state where everyone knows Github is getting all the development attention (and presumably most of the workforce now) but Microsoft is keeping it on just enough life support to keep companies "happy enough" and are still refusing to call it "dead". (They continue to point to the development roadmap, which is still actively maintained, but to some like me read very much like "bare minimum maintenance feature set". It also doesn't help that of the few open repositories for checking in on AzDO development, such as their community proposals repo, which are themselves hosted on Github, hah, it is very transparent most haven't seen active commits since 2019 or 2020.)
Bitbucket has a lot of Jira-integration and a lot of large corps are in Jira for the long haul now and "might as well get the synergy of Bitbucket".
Plus, don't underestimate the sunk cost fallacy factor keeping a lot of large corporations locked into things like Perforce and ClearCase.
Bitbucket has a lot of Jira-integration and a lot of large corps are in Jira for the long haul now and "might as well get the synergy of Bitbucket".
Plus, don't underestimate the sunk cost fallacy factor keeping a lot of large corporations locked into things like Perforce and ClearCase.
I worked at a company circa 2010 with around 2000 engineers that used git + gerrit + Jenkins + JIRA.
Worked at another company circa 2015 with around 80k employees (not sure how many engineers) that used git + cgit + Jenkins + JIRA.
Worked at another company circa 2015 with around 80k employees (not sure how many engineers) that used git + cgit + Jenkins + JIRA.
With my last four employers, two used subversion, one used git (just git -- not github or the like) and my current one uses whatever Azure Devops is using.
gitlab is what my company uses
Exactly this: I hate that GitHub is indeed very much like a social media. Expect also all the weird algorithmic surveillance to work underneath.
Self plug: https://sr.ht/~toastal/github-less-social/
I made a filter list for uBlock Origin (and compatible) ad-blockers that can hide many of the social media aspects of Microsoft GitHub to make it a bit more tolerable when forced to interact with it due to project lock-in.
I made a filter list for uBlock Origin (and compatible) ad-blockers that can hide many of the social media aspects of Microsoft GitHub to make it a bit more tolerable when forced to interact with it due to project lock-in.
I have seen it used on a commercial project, but I couldn't fathom why they were doing it. I guess business people did their thing. Large healthcare related project in the US.
An anecdote, but it's really difficult to search for information on git. Pretty much everything I find is specific to GitHub. Though that might be a problem with me still using Google to try to find information.
Yeah I switched to DuckDuckGo a long time ago and now I might switch to Brave Search because its "Goggles" feature is pretty cool (basically lets you rerank search results according to preference, ex: give precedence to tech blogs, or URLs popular in HN comments, down-rank most popular sites etc.).
This is getting off-topic, but at a certain point Google's results started to feel less and less relevant. Strict keyword matching stopped becoming a feature since it started to "guess" the "hidden meaning" behind your searches, modifiers like "include this exact text" and -"exclude this" stopped being supported and the amount of crap it throws in the search results that are not links to websites became distracting and annoying much of the time rather than useful.
This is getting off-topic, but at a certain point Google's results started to feel less and less relevant. Strict keyword matching stopped becoming a feature since it started to "guess" the "hidden meaning" behind your searches, modifiers like "include this exact text" and -"exclude this" stopped being supported and the amount of crap it throws in the search results that are not links to websites became distracting and annoying much of the time rather than useful.
Related to search though, Microsoft GitHub does not allow you to search the source code of projects with the search bar unless you are authenticated.
I would suggest bookmarking this: https://git-scm.com/book/en/v2 I have found the how and why of pretty much everything I've ever needed to do with git there. You can also access the official man pages on that site.
TBF the argument that some people use GitHub because it offers a more pleasant experience than using git itself (via the CLI) might have some truth to it. But saying "GitHub is what most people use because it makes the complexities of git easier" goes a bit too far. Local git GUIs like Sublime Merge are better for that - GitHub might help you with the complexities of collaborating with others using git, but it won't save your ass if you've got your local repo in some wonky state...
I agree with this. I was working on a project that was only available with Mercurial and I spent three days just trying to figure out how to not irreversibly corrupt my repo for a one-line change. I never figured it out and gave up since it wasn't super important.
I was happy when Atlassian finally sunset Mercurial, forcing those repositories to move to git. I'd rather all major source code hubs standardize on git since it's harder to contribute needing to learn different incompatible workflows.
I was happy when Atlassian finally sunset Mercurial, forcing those repositories to move to git. I'd rather all major source code hubs standardize on git since it's harder to contribute needing to learn different incompatible workflows.
Corrupting your repo with a one-line change? Is there more to this story? A bug report, for example? It's not my experience of Mercurial at all.
Even if Mercurial is fine, Git is really good and is the standard in most cases. It's not worth confusing new hires with an alternative repo system when Git is this good, this common, and also happens to be FOSS.
The usual argument for Mercurial, though, is that it's easier to use and more resistant to getting the local repo into odd states than Git. That tends to make Mercurial a better option for people without significant Git background, and definitely makes bad user experiences of that sort with Mercurial interesting.
I guess what I'm getting at is that Mercurial supporters tend to view it as distinctly better than Git, so sticking to Git just because of its widespread usage does feel like a sort of defeat... One could say similar about Fossil, a much more ambitious project that has faltered probably mostly due to Git claiming all the mind share.
I guess what I'm getting at is that Mercurial supporters tend to view it as distinctly better than Git, so sticking to Git just because of its widespread usage does feel like a sort of defeat... One could say similar about Fossil, a much more ambitious project that has faltered probably mostly due to Git claiming all the mind share.
They will screw up their local branch exactly once in their life.
I'm smiling a bit as today I've been trying to un-corrupt a git repo where lfs files were treated as repo files and vice versa. "where's by multi-mb binary, replaced by an ascii pointer file". how can I resolve ssh and https? ugh.
I recommend using git-remote-hg when dealing with Mercurial repos. Or git-cinnabar for very large ones like Mozilla's.
Git is great. It’s FOSS, but that doesn’t mean it’s immune to a hostile corporate takeover. Take email for example. It’s an open standard, yet it’s usage is dominated by large corporate players.
Email has the issue that it wants to be an arbitrary person-to-person communication protocol, which communicates through servers. Therefore, if I want to email you, the behavior of your server is my problem. The set of such people I may want to communicate with is large and heterogenous.
Git does not have that problem. If four of my buddies want to get together and start a startup together, and I start out by simply setting up git on an SSH server, the four of us do not care that GitHub recently extended the Git protocol with a hot new feature that only works on Windows 13. We just use our git. I am not in the position of wanting to share arbitrary source code with everyone in the world. The relevant social circles are much, much smaller.
I don't know that I'd say git is immune to such takeover, but it is about as resistant as it is feasible to be.
The problem with GitHub isn't git. In fact, that is the least problematic aspect of all. The git repo, the branches, the tags, commit history, signatures, that's all the stuff that is not only easy to take with you, the git protocol all but stuffs them all down your throat with a "git clone". You have to ask git not to give you a fully independent copy of the whole repo.
The problem with GitHub is all the other stuff; the issues, the PRs, the conversations in there, the fact you gave out so many URLs pointing to github, etc. The thing that makes me most nervous about GitHub and my Go libraries is that if GitHub does turn evil, I've got "github.com" embedded in a lot of people's source code. I've decided it's not quite worth it to host on my own domains (plus I imagine people look askance at that anyhow) but it's a long-term concern of mine.
Git does not have that problem. If four of my buddies want to get together and start a startup together, and I start out by simply setting up git on an SSH server, the four of us do not care that GitHub recently extended the Git protocol with a hot new feature that only works on Windows 13. We just use our git. I am not in the position of wanting to share arbitrary source code with everyone in the world. The relevant social circles are much, much smaller.
I don't know that I'd say git is immune to such takeover, but it is about as resistant as it is feasible to be.
The problem with GitHub isn't git. In fact, that is the least problematic aspect of all. The git repo, the branches, the tags, commit history, signatures, that's all the stuff that is not only easy to take with you, the git protocol all but stuffs them all down your throat with a "git clone". You have to ask git not to give you a fully independent copy of the whole repo.
The problem with GitHub is all the other stuff; the issues, the PRs, the conversations in there, the fact you gave out so many URLs pointing to github, etc. The thing that makes me most nervous about GitHub and my Go libraries is that if GitHub does turn evil, I've got "github.com" embedded in a lot of people's source code. I've decided it's not quite worth it to host on my own domains (plus I imagine people look askance at that anyhow) but it's a long-term concern of mine.
I don't get it, what exactly do you think is wrong with the email landscape? Its a standard protocol everyone can use, the only restrictions being when you start using other's services. Maybe I'm just not abreast enough on this.
I you want to send email from your server, you're entirely dependent on how the other servers run by the recipients view you. So if you have a bad IP address, they might not let your email through. The procedure for establishing yourself as a legitimate sender of email and not spam varies, and would need to be resolved with the operators of every server you might ever want to send mail to.
So you're running your mailing list which people have triple opted into, with confirmations and everything. Someone marks your email as spam and now everyone with a google address is bouncing. You contact google to resolve this and get a canned reply saying they've reviewed it, it's correct, and they will take no further action, and won't discuss it further. Good luck.
So you're running your mailing list which people have triple opted into, with confirmations and everything. Someone marks your email as spam and now everyone with a google address is bouncing. You contact google to resolve this and get a canned reply saying they've reviewed it, it's correct, and they will take no further action, and won't discuss it further. Good luck.
How does this detract from email, the standard?
Nobody said it does. The clarification of it detracting from email the standard is yours.
It nonetheless demonstrates how Pareto allows popular providers to make decisions that negatively impact those who want to exercise the freedom granted to them. It doesn’t run in isolation, after all.
It nonetheless demonstrates how Pareto allows popular providers to make decisions that negatively impact those who want to exercise the freedom granted to them. It doesn’t run in isolation, after all.
Considering that the user, LanceH, was directly replying to:
> I don't get it, what exactly do you think is wrong with the email landscape? Its a standard protocol everyone can use, the only restrictions being when you start using other's services. Maybe I'm just not abreast enough on this.
I would say most readers would interpret that as in response to email, the standard.
> I don't get it, what exactly do you think is wrong with the email landscape? Its a standard protocol everyone can use, the only restrictions being when you start using other's services. Maybe I'm just not abreast enough on this.
I would say most readers would interpret that as in response to email, the standard.
The reply made it clear that the problem is with the email landscape, not the protocol:
> you're entirely dependent on how the other servers run by the recipients view you.
A protocol can be bulletproof. But spammers will spam, blockers will block, trusted platforms will control.
> you're entirely dependent on how the other servers run by the recipients view you.
A protocol can be bulletproof. But spammers will spam, blockers will block, trusted platforms will control.
It impacts email as a standard because Google is a gatekeeper of what is supposed to be an open standard.
Google is a gatekeeper for it's customers. Which is quite fair I guess. You are not entitled to anyone else's inbox
And Google has such a dominant position in the marketplace that your only choice is to use Google (or a handful of other large providers). That was the thesis: E-mail is an open standard dominated by large corporations.
That is definitely not the only choice. There are services out there or you can also use your own servers. Google being big does not limit your choices on how to host your own email. Again, you are not entitled to other people's inboxes.
I have a few VPSes and domains, and tried to set up email on one of them recently.
Jumped through every hoop, got rDNS, SPF, DMARC, and DKIM all configured correctly...only to find out that the major email providers (at least Google and Microsoft, which account for a depressingly large fraction of email accounts) have decided that the VPS provider doesn't meet their standards, and either auto-block or mark as spam anything I send.
So I'm left with the choice of trying to migrate my entire VPS to a different provider—after figuring out which one, if any, Google and Microsoft actually deign to bless as being worthy of sending email to them—or not host my own email.
Jumped through every hoop, got rDNS, SPF, DMARC, and DKIM all configured correctly...only to find out that the major email providers (at least Google and Microsoft, which account for a depressingly large fraction of email accounts) have decided that the VPS provider doesn't meet their standards, and either auto-block or mark as spam anything I send.
So I'm left with the choice of trying to migrate my entire VPS to a different provider—after figuring out which one, if any, Google and Microsoft actually deign to bless as being worthy of sending email to them—or not host my own email.
The email standard never specified or guaranteed access to the majority of inboxes (or any inboxes in fact). It's literally just a technical standard to conform to or not. Successfully transmitting emails to another inbox is completely orthogonal and based on the personal, or corporate, decisions of the sender, receiver, and anyone else in the chain.
There is no provision for a fair shake, special categories for new entrants, or anything similar.
There is no provision for a fair shake, special categories for new entrants, or anything similar.
What value is an open standard if it can only be useful if you use an implementation from a large corporation. It’s a basic fact that email is only useful if your intended recipient can receive your message. If corporate gatekeepers are restricting valid usage outside of their walls, then it ceases to be an open standard. It’s like the difference between source available and open source.
The alternative is a spam and scam mess that would kill email.
BS. There are and were (I lament
dspam) excellent spam filters, plus if you enforce greylisting barely any spam gets through.
Indeed. And if we hit spammers with half the hammer that pirates have been hit with, it'd be a much smaller problem ... but for some reason, spam seems to be immune to legal action.
Spam inflates numbers and ends up benefiting nearly everyone except the end user in the short-term:
- Platforms benefit from larger activity volume, thus increasing their numbers and $$$
- FTC and other regulatory bodies get to take low-effort actions and tout the massive effects, ignoring the fact that they're slapping the ocean with a stick.
- All the systems in between are charging each other for artificial traffic, resulting in a convenient ponzi-like situation. I wouldn't be surprised if large chunks of vendor (SendgridTwilio, cloud providers, etc.) revenues are from illegitimate business.
I imagine a similar thing is happening in the phone space too. Scam calls are 99% of the calls I get on my cell phone now, and probably close to that for "revenue from calls" that the providers are raking in.
If I could spin up my own cell network like I could an email server and a domain, you bet that the big cell/telecom players would "blacklist" my domain for "spam" the moment they caught whiff and instantly make it almost useless, same as Gmail does.
If I could spin up my own cell network like I could an email server and a domain, you bet that the big cell/telecom players would "blacklist" my domain for "spam" the moment they caught whiff and instantly make it almost useless, same as Gmail does.
What about non-technical users? For my parents and siblings, using "free" online email from a major provider, like Google, Microsoft, or Yahoo certainly keeps them safer than old school POP3 (download to your PC). Email can get lost, scanning attachments was poor, and spam filtering was terrible, even by major Internet providers.
Dude... IMAP is decades old. I used Squirrelmail webmail when gmail came out.
In my pre-webmail experience, many ISPs did not offer IMAP as it requires them to keep email stored on their servers long term. The advantage of POP3: They force you to download it.
You can run an LLM in your browser now. Pretty sure even a low parameter LLM is more than capable of detecting spam. And thats not even considering more specialized approaches.
It is true that opt-in has bad UX. You can't easily "never send to spam".
Git lfs is a lousy hack. I wish git had better support for large binary formats.
The sad thing is that there's not much in Git's data model[1] that makes it bad for storing large binary blobs. An alternative implementation of Git (the program), or even a future version of vanilla `git`, could handle them just fine without the lfs hack, which I agree is horrendous, by using a different on-disk format for them and/or making sparse clones easier, and thereby remain 100% compatible with every other Git repository.
[1] There are some tweaks I would make, like using a standard Merkle tree hash function instead of sha1("blob "+size+"\0"+data), and a text-based encoding for commit and tree objects, but those are bike shed paint. I created a Git-like system based on these ideas that uses URNs and RDF/XML to make going 'under the hood' with a text editor a bit more pleasant than the experience with Git is, which is important because Git's tooling is far superior: https://github.com/TOGoS/ContentCouch/
[1] There are some tweaks I would make, like using a standard Merkle tree hash function instead of sha1("blob "+size+"\0"+data), and a text-based encoding for commit and tree objects, but those are bike shed paint. I created a Git-like system based on these ideas that uses URNs and RDF/XML to make going 'under the hood' with a text editor a bit more pleasant than the experience with Git is, which is important because Git's tooling is far superior: https://github.com/TOGoS/ContentCouch/
Shallow/sparse clones help with some of the pain points there, at least around time to clone and local repo size.
I’ve got Jenkins configured to heck and back. Still a hassle though, and it’s clear it’s not a full solution.
CVS used to be the standard before Git. Arguably CVS as the standard was not better than no standard if no standard let you use decentralized version control.
But Git is pretty good, so it will take something vastly better to replace it.
But Git is pretty good, so it will take something vastly better to replace it.
My understanding is that before git a substantial portion of the industry used the "one big shared drive and shouting across the room to lock files" version control system. There was also SVN that was pretty popular pre-git.
I don't believe any version control system achieved as deep industry penetration as git has.
I don't believe any version control system achieved as deep industry penetration as git has.
In my experience, SVN was _everywhere_ 10 years ago or so.
I used SVN once for my capstone project 11 years ago, graduated that same year, and literally haven't encountered it a single time in my career since then.
It definitely wasn't everywhere 10 years ago (but github was). Do you mean 15-20?
Regardless, having completed a CS degree during the period SVN was supposedly everywhere and only encountered it once because someone in my capstone team knew how to use it, I'm inclined to think it didn't permeate everything the way git does now.
If I could complete a bachelors in CS without encountering it in any of my courses, I think it's safe to say git is much more ingrained in the field now (pretty much every syllabus I come across online for CS courses from the last 5 years has had some github links)
It definitely wasn't everywhere 10 years ago (but github was). Do you mean 15-20?
Regardless, having completed a CS degree during the period SVN was supposedly everywhere and only encountered it once because someone in my capstone team knew how to use it, I'm inclined to think it didn't permeate everything the way git does now.
If I could complete a bachelors in CS without encountering it in any of my courses, I think it's safe to say git is much more ingrained in the field now (pretty much every syllabus I come across online for CS courses from the last 5 years has had some github links)
SVNs heyday is closer to 15 years ago at this point.
I've been in the industry for 25 years and have never seen it done that way anywhere. First place I worked used PVCS then migrated to Clear Case. The first free one I used was CVS.
I'd say each predecessor had about the same level of penetration, which was 'nearly all'. CVS->SVN-GIT. Git will be replaced. It's ripe for that - its interface is terrible, storage is now cheap, and many companies have no actual need for decentralized version control and the complexity that comes with it.
Easiest to use of the bunch is still svn. You can teach a developer everything they need to know in 5 minutes and there's 3-5 commands total you'll need to use ever. I never once saw anyone get into some nightmare state they needed help to dig out of like I've seen routinely with git.
I'd say each predecessor had about the same level of penetration, which was 'nearly all'. CVS->SVN-GIT. Git will be replaced. It's ripe for that - its interface is terrible, storage is now cheap, and many companies have no actual need for decentralized version control and the complexity that comes with it.
Easiest to use of the bunch is still svn. You can teach a developer everything they need to know in 5 minutes and there's 3-5 commands total you'll need to use ever. I never once saw anyone get into some nightmare state they needed help to dig out of like I've seen routinely with git.
subversion was just as dominant as git is now. Not using version control at all is probably just as common as it was previously.
That matches my experience too. SVN and CVS was very common as far as I remember. More developers probably use version control now than before, but version control was considered part of "best practice" before git was released.
There were of course places that were late to switch. I remember one of my old work places used P4 due to legacy in the CI/CD pipelines, but many teams kept a "shadow" git repository in Bitbucket with a bridge to P4. After a while, the company finally switched to Github Enterprise
There were of course places that were late to switch. I remember one of my old work places used P4 due to legacy in the CI/CD pipelines, but many teams kept a "shadow" git repository in Bitbucket with a bridge to P4. After a while, the company finally switched to Github Enterprise
SVN took over the hobbyist area rapidly due to its workflow/UI similarity to CVS, but P4 held fast professionally until at least 2015, as well as Source Safe if you were an MS shop. (And conservative places never switched off CVS at all.)
>one big shared drive and shouting across the room to lock files
yes ... how did you know we used visual source safe?
yes ... how did you know we used visual source safe?
By the mid-90's VSS supported exclusively locking files and requiring files to be locked before working on them.
Well, kinda? We did that. Then we discovered that about 10% of the time it didn't actually lock anything. So we included yelling across the room into our "grab it exclusively from VSS".
Yes, we had MS support, and they looked into it, and eventually basically shrugged (I'm told. I wasn't the one working with them).
Yes, we had MS support, and they looked into it, and eventually basically shrugged (I'm told. I wasn't the one working with them).
> a substantial portion of the industry used the "one big shared drive and shouting across the room to lock files"
Perhaps, but I've never seen that done. The version control system that is in fashion changes over time, but for my entire multidecade career there has always been one.
Perhaps, but I've never seen that done. The version control system that is in fashion changes over time, but for my entire multidecade career there has always been one.
If you take a look at Rapid Development (published 1996), one of the classic mistakes it lists is not using version control. A number of other 90s and earlier texts lament people not using version control.
Personally, a guy I dealt with circa 2010 stood up in a meeting on building better site-wide development processes, and asked what the point of version control was.
So, you've been lucky.
Personally, a guy I dealt with circa 2010 stood up in a meeting on building better site-wide development processes, and asked what the point of version control was.
So, you've been lucky.
Sure, I remember when that complaint was often cited. I'm just saying that using a version control system was the most common case even then. It wasn't as common as it should have been, though, that's true. But using version control was still common well before git came around.
Now, if you go back to the mid '80s and earlier, version control was rare.
Now, if you go back to the mid '80s and earlier, version control was rare.
> But Git is pretty good, so it will take something vastly better to replace it.
Git is fine, but honestly, my favorite of the several I've used over the years is still svn.
Git is fine, but honestly, my favorite of the several I've used over the years is still svn.
CVS, subversion and mercurial are all VCS tools that I remember using throughout the years. Didn't Microsoft even have its own for a while? I swear I remember Visual C++ integration features back in the 90s / early 00s but I can't remember what it was called.
Yes, MS Visual Sourcesafe (VSS). It was... not very good
Back in the late 90s we used to call it Visual SourceSieve - code changes would just leak away through the holes. Words cannot explain how much of a step up git (or even SVN) was.
As I recall, the main problem was that VSS didn't have a proper server! Instead the client modified files in the repository directly using Window's file sharing, relying on locks to maintain consistency. This would have been a bad idea even in Window's file shares weren't slow and buggy.
As I recall, the main problem was that VSS didn't have a proper server! Instead the client modified files in the repository directly using Window's file sharing, relying on locks to maintain consistency. This would have been a bad idea even in Window's file shares weren't slow and buggy.
I believe Visual Source Unsafe used the same storage layer as early versions of Exchange, which would break catastrophically when the underlying file grew past 2GB. Less than ideal.
they also had an internal source control system that they never released, which was a fork of perforce that they had purchased the rights to use and modify. Not sure if that's still in use in any projects.
It was, however, a step up from the shared network drive with a bunch of zip files.
Debatable. You would come into work in the morning and find that VSS had been corrupted and needed to be restored to an earlier backup. This was a common occurrence.
That the lovely common occurrence of someone checking out 1000 files and going on vacation.
I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
Team Foundation Version Control
Edit: And Visual Source Safe
Edit: And Visual Source Safe
Clearcase version control was a fun one.
Microsoft Visual SourceSafe
[deleted]
[deleted]
Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.
Merges are hard and I’ve never seen a system that removes the difficulty. I actually think git is the best because it’s easier to branch and update than many others (a pull takes a second to refresh vs quite a while for large repos with svn).
I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
I love rebasing.
As for dealing with merge conflicts, it's called
As for dealing with merge conflicts, it's called
- keep up to date with the branch your tracking
- merge frequently
- get on a call when you do have merge conflicts
- avoid having multiple people working in the same files simultaneously if possible
> As for dealing with merge conflicts, it's called
That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.
Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge.
I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial).
A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it.
But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it.
But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
well merging two wildly different of files is going to be complicated using any tool, git is not the issue there, there isn't a million ways to handle this
Right it's a use type thing.
If everyone develops from master branch and makes small incremental changes, no problem even if it's git.
If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either.
If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems
But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
If everyone develops from master branch and makes small incremental changes, no problem even if it's git.
If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either.
If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems
But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
There's three ways. One is the git way, which is to let people do whatever and then ask them to handle it afterwards. The next best is used by some other annoying system I used early in my career, which is to require people to check out a file before they can get write permission on it, and only allow one person to have write permission at once, so that there's no real risk of merges. And the worst of all is to just let whoever comes later overwrite whatever was there before.
The solution is darcs’ patch-theory model of development, currently being pushed forward by pijul.
I am making a VCS to compete against Git and Pijul.
The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt.
But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt.
But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
Please share when it is ready!
Absolutely! I am planning to make a "Show HN" my official announcement, but only after it is self-hosting and has enough features to replace my Gitea instance.
Mercurial's phases and changeset evolution make specifically rebasing far less painful. git rebase -i is downright antediluvian in comparison.
[deleted]
> But Git is pretty good, so it will take something vastly better to replace it.
Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it.
Don’t confuse inertia with goodness.
Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it.
Don’t confuse inertia with goodness.
Git is solving a very complicated problem with a command line tool. Don't confuse a complicated problem with a mediocre application.
Git is a mediocre CLI, imho, ymmv. GitHub I don’t have a strong opinion on.
But Git is not only the porcelain, it’s also the plumbing. Do you think that the plumbing is super mediocre too?
I don’t know what that analogy is supposed to mean. I don’t think analogies are necessary or appropriate here.
This is the terminology that Git uses. Porcelain is the UI, whether it’s the basic CLI, Magit, Fugitive, or anything else. Plumbing is Git under the UI.
Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are bad?
Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are bad?
Git’s CLI API is definitely bad.
I think the plumbing is probably in-between poor and bad for most projects. It’s maybe great for Linux. However almost all projects are effectively centralized so the D in DVCS is a waste. (Offline/local support and fully distributed are different). I think source control should make it impossible for 99% of users to shoot themselves in the foot. And Git is still terrible at large binary assets, even with Git-LFS.
I use Git + GitHub for my personal projects. It’s mediocre but tolerable. Git is insufficient and not used for every professional project I have ever worked on. YMMV.
I think the plumbing is probably in-between poor and bad for most projects. It’s maybe great for Linux. However almost all projects are effectively centralized so the D in DVCS is a waste. (Offline/local support and fully distributed are different). I think source control should make it impossible for 99% of users to shoot themselves in the foot. And Git is still terrible at large binary assets, even with Git-LFS.
I use Git + GitHub for my personal projects. It’s mediocre but tolerable. Git is insufficient and not used for every professional project I have ever worked on. YMMV.
Yeah, that makes sense. The CLI is definitely confusing. Every now and then you have draw on a book of spells to use it. I find it more comfortable with Magit but not sure if that makes up for all of the problems with the CLI.
What VCS would you use if it was all up to you?
What VCS would you use if it was all up to you?
> What VCS would you use if it was all up to you?
Almost 100% of game devs use Perforce. Git is a non-option.
BigTech all use highly custom source control systems. They have some nice properties.
My stance isn’t that we should use something other than Git per se. It’s that Git is a local maxima, and it kinda sucks. And I think the industry would be healthier if people agreed Git sucks.
Features I care about:
* Terabyte scale sparse checkouts * Ten terabyte scale full checkout * Petabyte scale history * Lossless history. * Automatic cloud/remote backups of every commit * Trivial for low-tech people to use (Perforce achieves this) * Cross-branch file locking for non-mergeable assets
Things I don’t care about:
* Distributed. Defacto centralized with forking is all I need. * Rewriting history. Linux needs it, I don’t.
There are of course lots of things I do like about Git. It’d be good if Git and Perforce had some competition. There’s a market opportunity for it imho.
Almost 100% of game devs use Perforce. Git is a non-option.
BigTech all use highly custom source control systems. They have some nice properties.
My stance isn’t that we should use something other than Git per se. It’s that Git is a local maxima, and it kinda sucks. And I think the industry would be healthier if people agreed Git sucks.
Features I care about:
* Terabyte scale sparse checkouts * Ten terabyte scale full checkout * Petabyte scale history * Lossless history. * Automatic cloud/remote backups of every commit * Trivial for low-tech people to use (Perforce achieves this) * Cross-branch file locking for non-mergeable assets
Things I don’t care about:
* Distributed. Defacto centralized with forking is all I need. * Rewriting history. Linux needs it, I don’t.
There are of course lots of things I do like about Git. It’d be good if Git and Perforce had some competition. There’s a market opportunity for it imho.
> At some point every industry grows up and standardizes on something, anything, because any standard is better than no standard.
What's the standard programming language? The standard editor? The standard database?
> launching a competing standard at this point isn't going to make things better, the best case scenario is that it fragments the industry.
People keep coming out with new programming languages, new editors, and new databases.
What's the standard programming language? The standard editor? The standard database?
> launching a competing standard at this point isn't going to make things better, the best case scenario is that it fragments the industry.
People keep coming out with new programming languages, new editors, and new databases.
The standard editor, if one had to give an answer, is probably VSCode at this point.
Likewise the standard DB may be Postgres.
Others exist but they’re certainly not the recommended defaults you find people giving out nowadays.
Likewise the standard DB may be Postgres.
Others exist but they’re certainly not the recommended defaults you find people giving out nowadays.
But no standard programming language, yes?
VSCode was not the standard seven years ago. ("In the 2016 Developers Survey of Stack Overflow, Visual Studio Code ranked No. 13 among the top popular development tools, with only 7% of the 47,000 respondents using it" says Wikipedia).
If lolinder's thesis is true, then that means it can take over 50 years before the industry decides on a standard. Which seems rather a long time for that statement to be meaningful. Because within 10 years maybe it will all change again.
FWIW, I've mostly used SQLite as my DB.
VSCode was not the standard seven years ago. ("In the 2016 Developers Survey of Stack Overflow, Visual Studio Code ranked No. 13 among the top popular development tools, with only 7% of the 47,000 respondents using it" says Wikipedia).
If lolinder's thesis is true, then that means it can take over 50 years before the industry decides on a standard. Which seems rather a long time for that statement to be meaningful. Because within 10 years maybe it will all change again.
FWIW, I've mostly used SQLite as my DB.
What on earth does 7 years ago have to do with 2023? Look at the 2022 survey, not one from 2016:
https://survey.stackoverflow.co/2022/#most-popular-technolog...
VSCode is overwhelming at a staggering 74%. ;P
https://survey.stackoverflow.co/2022/#most-popular-technolog...
VSCode is overwhelming at a staggering 74%. ;P
Git is certainly by far the de facto standard VCS. But I don't think lolinder's reasoning for why that is so has strong support, as it doesn't explain why other areas haven't already achieved the same standardization.
lolinder wrote "At some point every industry grows up and standardizes on something, anything, because any standard is better than no standard."
Either there was a standard editor before VSCode or there was not.
If there was a standard editor before VSCode, then it's clear that standards can change, which challenges lolinder's proposal that "launching a competing standard at this point isn't going to make things better". The VSCode developers likely thought it would make things better.
If it was no standard editor, then it took about 50 years for the industry to decide on one (dating from the late 1960s to 2016, when VSCode was definitely not the standard).
Leading to my observation that the "at some point" can take decades, and implies the urge to have a standard is not all that strong.
My memories of the 1990s was the CVS was the de facto standard, like how VSCode is now for text editors. Yet people fragmented the industry with SVN, BZR, Git, BitKeeper, Git, and more - because because they thought they could make things better. And at least one of them was right.
I'm therefore not so confident about rejecting launching an alternative to git. My limited understanding of Fossil, for example, tells me there are better approaches than git. (Then again, I'm a Mercurial user, so I already have my own preferences. ;)
lolinder wrote "At some point every industry grows up and standardizes on something, anything, because any standard is better than no standard."
Either there was a standard editor before VSCode or there was not.
If there was a standard editor before VSCode, then it's clear that standards can change, which challenges lolinder's proposal that "launching a competing standard at this point isn't going to make things better". The VSCode developers likely thought it would make things better.
If it was no standard editor, then it took about 50 years for the industry to decide on one (dating from the late 1960s to 2016, when VSCode was definitely not the standard).
Leading to my observation that the "at some point" can take decades, and implies the urge to have a standard is not all that strong.
My memories of the 1990s was the CVS was the de facto standard, like how VSCode is now for text editors. Yet people fragmented the industry with SVN, BZR, Git, BitKeeper, Git, and more - because because they thought they could make things better. And at least one of them was right.
I'm therefore not so confident about rejecting launching an alternative to git. My limited understanding of Fossil, for example, tells me there are better approaches than git. (Then again, I'm a Mercurial user, so I already have my own preferences. ;)
I remember using Perforce and Accurev about 10 years ago, and they were miles better than Git in terms of abstraction and feature set. I often miss being able to work on multiple branches with partially uncommitted local work for instance.
I do want the open-source world to improve and if we merely build on top of git's abstraction, how can we have any progress then?
I do want the open-source world to improve and if we merely build on top of git's abstraction, how can we have any progress then?
Salesforce uses Perforce internally, and it's a _massive_ source of problems for their giant monorepo precisely because there's no lightweight branching, so among the 1500+ developers working on the same codebase, _someone_'s always checking broken crap into the same branch all the time and causing huge headaches for everyone else.
When I left, they were investing a ton of time and developer hours into trying to duct-tape git onto their workflow by having smaller groups of developers share cached copies of their huge Perforce repo, and shunting the inevitable merge conflicts onto someone else and hoping for the best.
I spent a considerable amount of time training folks at my acquisition how to work in this environment, and roughly 70% of that time was "yes, Perforce _is_ weird and confusing and annoying, and yes, it _would_ be better if we had lightweight branches, but instead we're stuck in the version-control stone age of Perforce, so here's the complex process you can try to go through to un-break your own local codebase temporarily until someone else has fixed the broken crap they checked in."
When I left, they were investing a ton of time and developer hours into trying to duct-tape git onto their workflow by having smaller groups of developers share cached copies of their huge Perforce repo, and shunting the inevitable merge conflicts onto someone else and hoping for the best.
I spent a considerable amount of time training folks at my acquisition how to work in this environment, and roughly 70% of that time was "yes, Perforce _is_ weird and confusing and annoying, and yes, it _would_ be better if we had lightweight branches, but instead we're stuck in the version-control stone age of Perforce, so here's the complex process you can try to go through to un-break your own local codebase temporarily until someone else has fixed the broken crap they checked in."
For the specific use case you're describing, I've found `git worktree` to be very useful.
Overall, at least when it comes to features, I've actually had the opposite experience. That said, I'm one of those people such that you can pry `git rebase` out of my cold, dead hands, so it's that feature specifically that I really miss when I have to work with Perforce.
Overall, at least when it comes to features, I've actually had the opposite experience. That said, I'm one of those people such that you can pry `git rebase` out of my cold, dead hands, so it's that feature specifically that I really miss when I have to work with Perforce.
[deleted]
> Git is far from an ideal solution, but it has emerged as the standard way
Humans are such a weird species. The juxtaposition of the two arguments ("not ideal" and "the standard") is crazy to me. If it's not ideal, let's move away from it, not standardized on it. Is that too much to expect? :)
Humans are such a weird species. The juxtaposition of the two arguments ("not ideal" and "the standard") is crazy to me. If it's not ideal, let's move away from it, not standardized on it. Is that too much to expect? :)
English units (feet, pounds) are not ideal, and we have a better solution, yet ...
This is only true for alternatives to Git that are roughly equivalent in terms of complexity and time to learn. This wouldn't hold for an actual improvement (in productivity and training time), just like Rust, Zig or even Go are oven C++ and Java (the industry standards).
> I disagree that the dominance of git is a problem.
ok but that's not the argument of the article, so you aren't disagreeing with TFA. Maybe you're disagreeing with another top level comment.
TFA is arguing that the dominance of git hub is or is becoming a problem.
ok but that's not the argument of the article, so you aren't disagreeing with TFA. Maybe you're disagreeing with another top level comment.
TFA is arguing that the dominance of git hub is or is becoming a problem.
And there's an entire section that argues that git becoming entrenched as the standard is part of the problem with GitHub. That's what I was replying to.
> git itself, while not owned by GitHub, is even more popular. This is largely because of GitHub’s popularity and in spite of git’s poor UX. It would be nice to move beyond git one day and have a better experience for managing complex codebases, and not on GitHub’s timeline.
> ...
> I want to underscore this because I think it’s important: git and GitHub’s symbiosis are holding us back as an industry.
> ...
> Other version control software exists that doesn’t need a separate company to make the code accessible from the web or makes dealing with conflicts easier. We as an industry cannot benefit from these alternatives if we continue to use GitHub this heavily.
> git itself, while not owned by GitHub, is even more popular. This is largely because of GitHub’s popularity and in spite of git’s poor UX. It would be nice to move beyond git one day and have a better experience for managing complex codebases, and not on GitHub’s timeline.
> ...
> I want to underscore this because I think it’s important: git and GitHub’s symbiosis are holding us back as an industry.
> ...
> Other version control software exists that doesn’t need a separate company to make the code accessible from the web or makes dealing with conflicts easier. We as an industry cannot benefit from these alternatives if we continue to use GitHub this heavily.
thanks. i somehow glossed over those bits. i guess because i agree that the dominance of github is a disaster, so i was focused on the parts of TFA that i agree with.
like you, and i guess contrary to the article (again, like you), i think git itself as lingua franca is fine and maybe even great. certainly it has warts, some of them substantial, but what doesn't. we've come a long way since CVS and (shudder) SCCS.
like you, and i guess contrary to the article (again, like you), i think git itself as lingua franca is fine and maybe even great. certainly it has warts, some of them substantial, but what doesn't. we've come a long way since CVS and (shudder) SCCS.
There's a number of places out there, some of which also support alternatives to Git itself as mentioned in the article. By no means a complete list and in no particular order:
GitLab - https://about.gitlab.com/
Sourcehut - https://sourcehut.org/
Codeberg - https://codeberg.org/
Launchpad - https://launchpad.net/
Debian Salsa - https://salsa.debian.org/public
Pagure - https://pagure.io/pagure
For self hsoted options, there's these below projects, some of which power the above (and most of the above can be easily self hosted, too, it's just that this list doesn't have any hosting from the project itself):
Forgejo - https://forgejo.org/
Gitea - https://gitea.io/en-us/
Gogs - https://gogs.io/
GitLab - https://about.gitlab.com/
Sourcehut - https://sourcehut.org/
Codeberg - https://codeberg.org/
Launchpad - https://launchpad.net/
Debian Salsa - https://salsa.debian.org/public
Pagure - https://pagure.io/pagure
For self hsoted options, there's these below projects, some of which power the above (and most of the above can be easily self hosted, too, it's just that this list doesn't have any hosting from the project itself):
Forgejo - https://forgejo.org/
Gitea - https://gitea.io/en-us/
Gogs - https://gogs.io/
Not shilling here, but big upvote for Sourcehut - https://sourcehut.org/
When you pay money to Drew DeVault and his crew, their work is all open source. And, that includes work outside of Sourcehut. They are also hired guns for existing open source projects.
When you pay money to Drew DeVault and his crew, their work is all open source. And, that includes work outside of Sourcehut. They are also hired guns for existing open source projects.
My issue with Sourcehut is their arbitrary exclusion of certain classes of floss software. They're of course within their right to refuse hosting any software they don't like, but their ideologically-driven stance leaves a foul taste in my mouth and sets a horrible precedent for other misguided folks to follow.
If sourcehut is ever accepted as it is now and grows to become a major hosting platform for floss software, the entire floss ecosystem will suffer as a result.
For this reason I hope they correct course or remain forever insignificant.
If sourcehut is ever accepted as it is now and grows to become a major hosting platform for floss software, the entire floss ecosystem will suffer as a result.
For this reason I hope they correct course or remain forever insignificant.
My issue with Sourcehut is their arbitrary exclusion of certain classes of floss software.
Looks like a nice set of features, but that UX isn't going to win anyone over from Github/Gitlab/Gitea land.
I haven’t used Gitea but I hate GitHub and GitLabs’ UI.
I find it a giant mess of noise and basically cringe until I get to the specific project root and readme.
GitLab in particular seems to move settings and functions around on the page so I’m hunting for where the history or blame is.
I find it a giant mess of noise and basically cringe until I get to the specific project root and readme.
GitLab in particular seems to move settings and functions around on the page so I’m hunting for where the history or blame is.
Some basic spacing and font work would go a long, long way for SourceHut.
SourceHut doesn't require Javascript. If that means a _simple_ user interface, I'll take it.
Also, I forgot about it's performance index too: https://forgeperf.org/
[deleted]
Also upvoting for Sourcehut. I don't publish much of my code these days but Sourcehut is to me what GitHub was earlier before it got bit.
"There's a number of places out there, some of which also support ..."
Remember, also, that 'git' is built into the rsync.net environment and allows you to manipulate these providers without involving your local connection or machine.
For instance, when I want to mirror a repo I consider interesting or important:
https://git-annex.branchable.com/
... which solves some interesting problems.
"git-annex is designed for git users who love the command line. For everyone else, the git-annex assistant turns git-annex into an easy to use folder synchroniser."
Remember, also, that 'git' is built into the rsync.net environment and allows you to manipulate these providers without involving your local connection or machine.
For instance, when I want to mirror a repo I consider interesting or important:
ssh [email protected] "git clone git://github.com/freebsd/freebsd.git freebsd"
https://git-annex.branchable.com/
... which solves some interesting problems.
"git-annex is designed for git users who love the command line. For everyone else, the git-annex assistant turns git-annex into an easy to use folder synchroniser."
[deleted]
There's also Atlassian Bitbucket. Which we're moving away from, because they do not support arm Docker builds. They don't support it because it requires privileged flag, and so it would give access to other builds on the same machine...
So apparently there's two great reason to move away from Bitbucket. Not supporting arm builds and apparently you're one exploit away from other builds on the same machine having access to yours?
https://jira.atlassian.com/browse/BCLOUD-15317
So apparently there's two great reason to move away from Bitbucket. Not supporting arm builds and apparently you're one exploit away from other builds on the same machine having access to yours?
https://jira.atlassian.com/browse/BCLOUD-15317
I haven't used Bitbucket for a long time, but from what I remember it had a superior merge/pr tool. It was much easier to follow review comments after a rebase or commit. Is that still the case?
Yes, the Bitbucket PR screen is really good. Even when a commit removes the code a comment is tied to, it still shows it as an "outdated comment" or some verbiage like that. The approval controls available are pretty good too. But we've loosened up on the use of these a bit, as we're a really small group and the overhead was not worth the control for known and trusted actors.
Hey - PM from the Bitbucket Cloud Pipelines team here. We're actually kicking off internal beta testing of ARM runners for Bitbucket Pipelines as we speak.
If you're interested in being involved in that EAP please reach out to me at [email protected]
Also "git + ssh" can be a sufficient stack in and of itself.
It's not that there aren't alternatives. There are plenty. (And how'd you miss gerrit!)
It's that github has become a platform. More users = more success and github is commercially motivated, so it is motivated to create a proprietary platform which is incompatible with other proprietary platforms. There are many built-in features that are hard to fund if you're not successful (have enough revenue), and there are many 3p integrations that 3p won't bother to implement for non-github targets. Thus cementing a github monopoly.
It's that github has become a platform. More users = more success and github is commercially motivated, so it is motivated to create a proprietary platform which is incompatible with other proprietary platforms. There are many built-in features that are hard to fund if you're not successful (have enough revenue), and there are many 3p integrations that 3p won't bother to implement for non-github targets. Thus cementing a github monopoly.
Bitbucket - https://bitbucket.org/
Also add the cloud providers
AWS CodeCommit
GCP Cloud Source Repositories
Azure Repos
Also add the cloud providers
AWS CodeCommit
GCP Cloud Source Repositories
Azure Repos
Honestly moving from GitHub to Azure Repos is kind of a braindead move lol, at least if your objective is to get away from Microsoft.
Including that AzDO looks very "zombie" now and it seems obvious Github has the most resources and is getting the most development effort. Microsoft sometimes has the reputation for being fast to pull the trigger to kill a dead, redundant project, but AzDO is a clear example that they don't.
How is Codeberg? Has anyone used it extensively? I like the sound of it being run by a non-profit with a FOSS focus, so I'm curious.
I've used it on personal projects and it's very good and the Gitea/Forgejo/Codeberg community is quickly trying to catch up with GitHub on UX and features.
The only thing it lacks is the large network effect of GitHub, but hey, it's still a network and you can help it grow.
Another hinderance I found is that many edge webhosts that build your node apps from source code for you only have a GitHub or sometimes also Gitlab integration, but none for Gitea and it's children or even just arbitrary hosted git repos...
Another hinderance I found is that many edge webhosts that build your node apps from source code for you only have a GitHub or sometimes also Gitlab integration, but none for Gitea and it's children or even just arbitrary hosted git repos...
Thanks!
You can also self-host gitlab.
We've been self hosting it in our company for few years and it's been a good experience so far.
We've been self hosting it in our company for few years and it's been a good experience so far.
Ignoring all of the great social/community features like having pages for trending repos/developers and things of that nature that I check frequently, the Github Actions marketplace is a game changer. CircleCI has Orbs but there are so, so many fewer since the community is so much smaller. I'm not sure if Gitlab has anything similar yet.
With that said, I really need a CI system that has a maintenance mode button so I can do 250 failing builds fixing pipelines (I'm ops) and not spam everyone with emails from my specific branch..
edit: Well, I don't know how true it is but I asked chatgpt about maintenance mode and it definitely exists (supposedly) -- Yes, many Continuous Integration (CI) systems allow you to configure maintenance mode or similar settings to prevent notifications for certain branches or builds. This can be useful if you want to perform maintenance on a branch or temporarily disable a build without triggering unnecessary notifications.
edit: It also says CircleCI has one.. so.. I will dig around, sorry to CircleCI if I was totally wrong initally.
lastedit: I don't see it anywhere.. shrug.
With that said, I really need a CI system that has a maintenance mode button so I can do 250 failing builds fixing pipelines (I'm ops) and not spam everyone with emails from my specific branch..
edit: Well, I don't know how true it is but I asked chatgpt about maintenance mode and it definitely exists (supposedly) -- Yes, many Continuous Integration (CI) systems allow you to configure maintenance mode or similar settings to prevent notifications for certain branches or builds. This can be useful if you want to perform maintenance on a branch or temporarily disable a build without triggering unnecessary notifications.
edit: It also says CircleCI has one.. so.. I will dig around, sorry to CircleCI if I was totally wrong initally.
lastedit: I don't see it anywhere.. shrug.
Gitlab has a templating system for pipelines and comes with an extensive collections of templates builtin, which they call 'Auto DevOps'. You can use the same templating engine to create building blocks for pipelines in your org, or open source them to share with the community.
However, I don't think there's a default distribution of common templates, so there's not really a marketplace. Which surprises me a bit though, it could be as simple as setting up a 'blessed' repository, mention it in the docs, add some guidelines and resources to review the merge requests.
Here's the repo for the builtin templates, if you browse them you'll quickly get feel for how they work: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitla...
I liked working with templates much more than github actions, but maybe that's me.
However, I don't think there's a default distribution of common templates, so there's not really a marketplace. Which surprises me a bit though, it could be as simple as setting up a 'blessed' repository, mention it in the docs, add some guidelines and resources to review the merge requests.
Here's the repo for the builtin templates, if you browse them you'll quickly get feel for how they work: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitla...
I liked working with templates much more than github actions, but maybe that's me.
Agreed - I'm a bit Gitlab fan, but it does seem as though sometimes there just aren't enough people floating around their tickets and code to actually get stuff like this done. Sometimes they languish for years.
Here's an example: Review Apps. Cool idea, but you'd better have a working K8s cluster with ingress ready to go. When they could add a managed k8s (or something else dockerisable) just for Review Apps inside Gitlab itself.
Here's an example: Review Apps. Cool idea, but you'd better have a working K8s cluster with ingress ready to go. When they could add a managed k8s (or something else dockerisable) just for Review Apps inside Gitlab itself.
FWIW, k8s is only the default for review environments, AFAIK. As long as the stage associated with the `review_environment:` key is able to bring up an application on the review_environment's `url:` and then tear it down on review_environment:stop, then that's it. One could use ECS, or php, or any of the other "push button, get URL" setups out there
Unless your comment was made specifically in response to the Auto DevOps part, in which case, yes, they're optimizing for the happy path, not for every possible system in the universe
Unless your comment was made specifically in response to the Auto DevOps part, in which case, yes, they're optimizing for the happy path, not for every possible system in the universe
Recently someone posted this on HN: https://blog.r2devops.io/blog/All/GitLab_Marketplace/
This is why we started using Earthly. We still use Github Actions, but 95% of our actual CI logic is now encoded in Earthly, which can be run locally on any developer's machine (assuming they have Docker installed). Ironically, it still took me half a day of screwing with Github Actions to get Earthly to run correctly (mostly permissions for pushing images), but since then I've not had to touch it and can do all of my troubleshooting locally.
Last time I checked there was a ticket CircleCI on their support asking to be able to built the result of a PR and not just the HEAD of the branch.
That ticket was still open after 7 years.
Even TeamCity had that functionality.
That's when they lost my $.
That ticket was still open after 7 years.
Even TeamCity had that functionality.
That's when they lost my $.
> Even TeamCity had that functionality.
If something as fragile and arcane as TeamCity has this then that reflects very poorly on CircleCI
If something as fragile and arcane as TeamCity has this then that reflects very poorly on CircleCI
We did this with CircleCI by just ticking the "PR branches must be up to date" box in GitHub. It's more a Git provider thing than a CI thing.
You run into problems keeping branches up to date manually with bigger teams, because every time a PR lands on main it requires everyone else with a PR up to merge main back in. If the CI handles this automatically it saves a lot of time.
Fair enough, but if you have lots of branches, won't the CI be constantly rerunning as PRs are merged? Or is that the intended behaviour? I would imagine CircleCI, that bills per-minute of CI, might like that, but its customers might not :)
> asked chatgpt about maintenance mode and it definitely exists
GitHub has a feature called Maintenance Mode, but its for enterprise customers and doesnt do what you want. Probably hallucinated the rest.
GitHub has a feature called Maintenance Mode, but its for enterprise customers and doesnt do what you want. Probably hallucinated the rest.
GitLab team member here. We just published a blog post[0] yesterday on how GitLab users can build more reusable CI templates. If you read until the end, you'll be find information about our plans for components and a components catalog.
[0] - https://about.gitlab.com/blog/2023/05/01/how-to-build-reusab...
[0] - https://about.gitlab.com/blog/2023/05/01/how-to-build-reusab...
Is it just me, or does the PR experience with Github leave a lot to be desired? Unlike some, I don't have a problem with the concept of a PR per se, but I frequently find navigating the various conversations in my PRs more difficult than I feel it should be. If a branch is rebased, then comments on code that was changed get lost, and one has to go the Conversations tab and search for the comment there. I understand that the commit itself is gone, which is fine, but I think an easy way to navigate through the comments, even if their context is lost, would be a great improvement.
I am actually more interested in the suggestion to try VCS alternatives, though. To me, it seems like we have reached a local maximum with git where in principle, better approaches exist, but no one seems to think the cost of switching would be worth it.
I am actually more interested in the suggestion to try VCS alternatives, though. To me, it seems like we have reached a local maximum with git where in principle, better approaches exist, but no one seems to think the cost of switching would be worth it.
The PR experience on github is crazy bad. The commentary only works for a single round. After the first round of review, nobody can find where/why the comments were placed, or whether/how they were addressed. For me Gerrit is much better.
> If a branch is rebased, then comments on code that was changed get lost
That's probably more related to UX than git itself. I remember Bitbucket (also git) handling these situations better and conversations were much easier to follow, but I haven't used it in a few years so things could have changed.
That's probably more related to UX than git itself. I remember Bitbucket (also git) handling these situations better and conversations were much easier to follow, but I haven't used it in a few years so things could have changed.
> I don't have a problem with the concept of a PR
I don't either; the idea of a change-set as the unit of source control works well. My problem is that git doesn't work that way. Every git workflow I've seen, including GitHub PRs, and to a large extent git itself, presents the illusion that a git commit is a change set. When you write a git commit message, you probably write it as if it were describing a set of changes. When you run `git show 21ad6ef3`, git shows you changes, as if `21ad6ef3` referred to those changes. But it doesn't.
The GitHub approach is interesting in that it actually does retain the change-set (PR) as part of the project history. But it's out-of-band with respect to the actual git repository.
I don't either; the idea of a change-set as the unit of source control works well. My problem is that git doesn't work that way. Every git workflow I've seen, including GitHub PRs, and to a large extent git itself, presents the illusion that a git commit is a change set. When you write a git commit message, you probably write it as if it were describing a set of changes. When you run `git show 21ad6ef3`, git shows you changes, as if `21ad6ef3` referred to those changes. But it doesn't.
The GitHub approach is interesting in that it actually does retain the change-set (PR) as part of the project history. But it's out-of-band with respect to the actual git repository.
> an easy way to navigate through the comments, even if their context is lost, would be a great improvement.
Sounds like you want to filter the conversation view so that you can separate the various things shown there (PR comments, code comments, reviews)? Seems like a useful feature.
Sounds like you want to filter the conversation view so that you can separate the various things shown there (PR comments, code comments, reviews)? Seems like a useful feature.
Yes, that would be a good way of doing it.
a former employer of mine insisted we use phabricator (self-hosted) instead of github. while I initially fought it because of vpn requirement and UI/UX differences after years of github, I grew to quite like it. in particular the comment organization, handling of back-merges to trunk, and workflow standardization. not sure if it’s still maintained or not though
https://www.phacility.com/phabricator/
> Effective June 1, 2021: Phabricator is no longer actively maintained.
> Effective June 1, 2021: Phabricator is no longer actively maintained.
Yeah and PRs don't scale well for popular repos with a small number or single maintainer. It's just an unbelievable amount of work to throw code at someone and let them figure out if it's high enough quality, worth integrating and maintaining, etc. It just leads to burn out and abandonment. IMHO there should be much more focus on the branching nature of git and highlight that code can and should live in different user branches.
“ You can see similar features in GitHub’s smaller competition Codeberg, GitLab, BitBucket, and Gitea. These competitors don’t offer other, major code collaboration tools, and their Pull Request-like features aren’t just there to help users come from GitHub.“
That's where I stopped reading. GitLab’s Merge Requests are on par or even more robust than GitHub’s Pull Requests.
This person clearly hasn't used GitLab; otherwise, they wouldn’t say this.
Blank statements like this one undermine their core argument.
That's where I stopped reading. GitLab’s Merge Requests are on par or even more robust than GitHub’s Pull Requests.
This person clearly hasn't used GitLab; otherwise, they wouldn’t say this.
Blank statements like this one undermine their core argument.
Having used GitLab, GitHub, and BitBucket in enterprise, I actually prefer gitlab-ci to github actions. GitLab feels buggier overall (so many lines in my .github-ci.yml were prefaced with a link to the GitLab issue requiring me to do some hack instead of what the docs suggested), but the PR tooling was good enough on all of them for everything I was doing.
I don't think things like this really need proactive measures. If GitHub becomes a problem there are dozens of alternatives for every piece of the pipeline. I get winded by all these posts that claim we need to be cautious about every step we make.
This isn't proactive; the article listed several ways in which GitHub is now a problem.
I think GitHub has generally been a really good thing for devs. It has added some good opinions on how we ought to work. Specifically I would say:
* Pull requests as a major dev artifact. Probably the most reliable tracker of a set of decisions at a point in time
* The connection of the issue tracker to the code base and not as a separate tool (ie Jira).
* Expectation of a basic README with the project with the basic documentation.
We take these things for granted now, but pre GitHub this was NOT the norm.
I’m not sure I frankly want a competitor here. It’s one extra annoying thing for me to think about. Opinions are good for streamlining my life as a dev.
* Pull requests as a major dev artifact. Probably the most reliable tracker of a set of decisions at a point in time
* The connection of the issue tracker to the code base and not as a separate tool (ie Jira).
* Expectation of a basic README with the project with the basic documentation.
We take these things for granted now, but pre GitHub this was NOT the norm.
I’m not sure I frankly want a competitor here. It’s one extra annoying thing for me to think about. Opinions are good for streamlining my life as a dev.
> basic README
GitHub (plus the wide adoption of the incredibly-limited Markdown) is the reason we no longer see a a README but a RENDERME. Have you tried to read most README.md files now? They’re filled with so many images and HTML that make it no longer readable without first rendering it (one example: how does an _image_ of CI status and other badges help me at all when I open the plaintext? In many cases, a definition list would be better, but Markdown doesn’t support it). The problem is then further exacerbated by ‘GitHub-flavored Markdown’, a syntax fork that now makes your Markdown incompatible with other forges; in the case of trying to shoehorn in admonition (feature lacking from Markdown) Microsoft GitHub is overloading the blockquote element via `>` ruining not just compatibility/portability but also HTML semantics as it’s still rendered inside a <blockquote> element.
The READMEs of yore were usually ASCII-only docs akin to old GameFAQs guides that didn’t require a render step. They lacked accessibility that HTML can provide, but aside sick ASCII art banners, didn’t have all that cruft that should be in the project’s landing page not README.
GitHub (plus the wide adoption of the incredibly-limited Markdown) is the reason we no longer see a a README but a RENDERME. Have you tried to read most README.md files now? They’re filled with so many images and HTML that make it no longer readable without first rendering it (one example: how does an _image_ of CI status and other badges help me at all when I open the plaintext? In many cases, a definition list would be better, but Markdown doesn’t support it). The problem is then further exacerbated by ‘GitHub-flavored Markdown’, a syntax fork that now makes your Markdown incompatible with other forges; in the case of trying to shoehorn in admonition (feature lacking from Markdown) Microsoft GitHub is overloading the blockquote element via `>` ruining not just compatibility/portability but also HTML semantics as it’s still rendered inside a <blockquote> element.
The READMEs of yore were usually ASCII-only docs akin to old GameFAQs guides that didn’t require a render step. They lacked accessibility that HTML can provide, but aside sick ASCII art banners, didn’t have all that cruft that should be in the project’s landing page not README.
Yes GitHub contributed to advancing the software industry but now it's been acquired by Microsoft and good alternatives have emerged so time has come to move on.
Everything flows.
Everything flows.
Raise your hand if you want your open source project to show up when somebody is searching. Or if you maintain a github mirror so that your project doesn't languish in obscurity. There is one thing that is truly essential for alternative platforms: easy discovery of projects. I think for alternative platforms to have a chance you need to somehow have a global, platform independent index of software projects that live on different repositories. You can then show them to people on equal footing irrespective of where they are hosted.
I think you’re very right about this. To me:
- It’s important that my repos show up in GitHub search (self promotion, essentially). - In the ‘other direction’, Github search feels fairly comprehensive. I don’t feel the need to search for things elsewhere.
This is obviously rather self-reinforcing. For an independent index to be successful it needs to be _better than GitHub search_ ad searching GitHub, which seems challenging.
It doesn’t help that if I see results that seem to be indexing GitHub in a Google search nowadays, I assume they’re SEO spam.
Two other things I find important:
- It’s easy to fork repositories. - It’s easy to contribute back to repositories I’ve forked.
Gitea really should be focusing on making it a first class UI concept to fork got repos from elsewhere. I know they’re also working on ‘federated’ pull requests - though making them _to Github repos_ seems like a more challenging idea, and is probably just as important.
- It’s important that my repos show up in GitHub search (self promotion, essentially). - In the ‘other direction’, Github search feels fairly comprehensive. I don’t feel the need to search for things elsewhere.
This is obviously rather self-reinforcing. For an independent index to be successful it needs to be _better than GitHub search_ ad searching GitHub, which seems challenging.
It doesn’t help that if I see results that seem to be indexing GitHub in a Google search nowadays, I assume they’re SEO spam.
Two other things I find important:
- It’s easy to fork repositories. - It’s easy to contribute back to repositories I’ve forked.
Gitea really should be focusing on making it a first class UI concept to fork got repos from elsewhere. I know they’re also working on ‘federated’ pull requests - though making them _to Github repos_ seems like a more challenging idea, and is probably just as important.
> Their goals only align with yours if your goal is to make GitHub more profitable.
Er, no. Their goal is to make github more profitable. My goal is to have a convenient code repository that facilitates both devops and code collaboration within our team. Our goals still align.
Er, no. Their goal is to make github more profitable. My goal is to have a convenient code repository that facilitates both devops and code collaboration within our team. Our goals still align.
You are assuming for some reason that they won't sacrifice your convenience for their profits. Or maybe you think it's impossible to profit from limiting customer convenience?
When they do, then our goals will misalign :-)
They already do sacrifice convenience for profit.
Subjective. I think GitHub is the most convenient for my use case. That's why I pay for it. Like OP if they sacrifice MY convenience then we misalign.
The big thing here is that nobody else satisfies my convenience like GitHub does.
Also all of these companies are for profit, so to pick on GitHub for trying to make a profit is disingenuous.
The big thing here is that nobody else satisfies my convenience like GitHub does.
Also all of these companies are for profit, so to pick on GitHub for trying to make a profit is disingenuous.
I think Github have already won the cultural dev war. I hear many a developer saying Github instead of "Git".
A recent example from a mid level dev:
"I'm gonna branch from the github repository" - when the repository is self hosted
A recent example from a mid level dev:
"I'm gonna branch from the github repository" - when the repository is self hosted
I've never heard/seen it that way around before, but calling GitHub (or similar) features/sites 'git' all the time...
Docker too. ('a docker')
Docker too. ('a docker')
I'm surprised GitHub isn't trying to avoid their trademarked becoming generic [1].
If that keeps up you can just call your alternative repo storage system GitHub 2.0 or GitHub Enterprise or something.
[1]: https://en.wikipedia.org/wiki/Generic_trademark
If that keeps up you can just call your alternative repo storage system GitHub 2.0 or GitHub Enterprise or something.
[1]: https://en.wikipedia.org/wiki/Generic_trademark
My current company uses GitLab; anyone mistakenly referring to it as "Github" would get swiftly corrected, even as a simple proxy word for "Git".
I do that just to mess with people
How does it mess with people? Perhaps they just quietly assume you're not too bright?
I very loudly assume.
Was it a self hosted github instance?
No, https://git-scm.com/downloads
Github != Git
Github != Git
You cant self host github.
That's what github enterprise is for
Im pretty sure thats a junior dev thing, no?
Indeed. Not different than many folks saying "internet" instead of "www".
That developer is mid level in title, but not in skill.
I agree that allowing a company, especially Microsoft which is a cunning corporation, to corner the software development and open source community through its GitHub/VS Code one-two punch is not good for the industry/community. Add using GitHub data for training AIs on top and now a single corporation has immense market power and influence on the direction of technology.
Considering what GitHub offers, MS derives far more value then devs get, and devs risk getting stuck within their system, providing value for MS but getting far less in return. Why give a corporation so much for free at such a large cost to the industry/community?
Considering what GitHub offers, MS derives far more value then devs get, and devs risk getting stuck within their system, providing value for MS but getting far less in return. Why give a corporation so much for free at such a large cost to the industry/community?
Of my last 4 customers, three are using Bitbucket, one is using GitHub. One is using Bitbucket's Pipelines (never head about), one Semaphore (same thing), one Travis (with GitHub), one runs tests locally and deploys from a self-hosted TeamCity instance. Almost every single external package all those four customers use has its repository on GitHub.
Hey - when you say you 'Never head about' in relation to Bitbucket Pipelines, do you mean you'd never heard that Pipelines was a product that was available as part of Bitbucket?
Asking as I took over as the PM for Bitbucket Pipelines around 6 months ago and have been working to make the case for us needing to do a lot more to make people aware of the capability as a lot think Bitbucket is just Git, not CI/CD as well.
Asking as I took over as the PM for Bitbucket Pipelines around 6 months ago and have been working to make the case for us needing to do a lot more to make people aware of the capability as a lot think Bitbucket is just Git, not CI/CD as well.
First of all, sorry for the spelling mistake (head/heard.)
You are correct, I didn't know about Pipelines. However I don't use Bitbucket myself. I only use it when a customer uses it and this was the first customer of mine that uses Pipelines. I remember that I setup a pipeline for a new project and it was easy to do it.
In general I'm always surprised by the amount of different products that do the same thing and I never heard about. The diversity is good, my ignorance is bad. However there is a limit on the number of things one can use.
You are correct, I didn't know about Pipelines. However I don't use Bitbucket myself. I only use it when a customer uses it and this was the first customer of mine that uses Pipelines. I remember that I setup a pipeline for a new project and it was easy to do it.
In general I'm always surprised by the amount of different products that do the same thing and I never heard about. The diversity is good, my ignorance is bad. However there is a limit on the number of things one can use.
Thanks so much for taking the time to reply, little anecdotes like this do a lot to help me make the case for us needing a better brand.
Completely understand where you're coming from re: the number of different tools. Obviously I'd love it if we were one of the one's people thought of when the topic of integrated Git + CI/CD came up, but that's on us to change the level of awareness.
Completely understand where you're coming from re: the number of different tools. Obviously I'd love it if we were one of the one's people thought of when the topic of integrated Git + CI/CD came up, but that's on us to change the level of awareness.
Well I work with gitlab since ~10 years or so, and to be fair this seems wrong:
> These competitors don’t offer other, major code collaboration tools [...] They looked at the dominant player and did the same.
It really feels the opposite to me with gitlab:
- CICD were in gitlab before github action, and is still way more complete in gitlab
- gitpod was here before codespace
- infrastructure and dependency management was in gitlab before github, and still needs third party to be as complete as gitlab
- custom and licence compliance is still incomplete in github, still needs third party stuff ...
My 2 cents: GitHub profits from heavy projects and a better marketing team than Gitlab
But yes, GitLab is at it's full potential only when you pay ...
> These competitors don’t offer other, major code collaboration tools [...] They looked at the dominant player and did the same.
It really feels the opposite to me with gitlab:
- CICD were in gitlab before github action, and is still way more complete in gitlab
- gitpod was here before codespace
- infrastructure and dependency management was in gitlab before github, and still needs third party to be as complete as gitlab
- custom and licence compliance is still incomplete in github, still needs third party stuff ...
My 2 cents: GitHub profits from heavy projects and a better marketing team than Gitlab
But yes, GitLab is at it's full potential only when you pay ...
Gitlab is a worse user experience for people looking at your repo and code online. It doesn't even display a list of files without javascript. And even when it does it take 5 cores at 100% to do a directory listing of gtk3. It's really a terrible web interface no matter how nice the dev side git interface is.
GitLab is also open-core and publicly-traded. For now, I appreciate what they do and how the issue tracker is mostly public, but when the investors say “it’s time to turn this into a money printing machine so I can get my ROI”, I don’t know that I have a lot of confidence in it in the long run.
"The Pull Request workflow is so dominant now that it’s considered the default path for code to permanently enter into a repository."
Arguably this model has less to do with GitHub becoming dominant but with the fact that all of the large BigCorp/FAANG type companies now use a strict code review policy, and this has spread downwards (along with a bunch of other cargo cult-ed practices) into much smaller organizations.
The first 10-15 years of my career I never encountered a code review tool once, and it was just commit privileges granted or not granted and judicious use of branching and tagging. Then everybody seemingly started to switch from "I'll just go off and do my work on a branch and then we'll integrate" to "I don't trust anything anybody else has written and we'll review every single line".
I worked at Google for 10 years and when I emerged from there everyone had switched to code review, even small startups.
FWIW I see advantages and disadvantages to both approaches. But I don't think GitHub is to blame? Google clearly has an intrinsic interest in making sure things don't blow up $$ production, and are willing to sacrifice velocity all over the place to make sure of that. Same with projects like the Linux kernel, or GCC or LLVM or whatever. But...
(If anything, Git makes working on longer running feature branches a lot easier, and the whole code/pull review process made more sense with centralized systems like Perforce, etc. or systems like CVS or SVN that had terrible merge-on-merge support)
Arguably this model has less to do with GitHub becoming dominant but with the fact that all of the large BigCorp/FAANG type companies now use a strict code review policy, and this has spread downwards (along with a bunch of other cargo cult-ed practices) into much smaller organizations.
The first 10-15 years of my career I never encountered a code review tool once, and it was just commit privileges granted or not granted and judicious use of branching and tagging. Then everybody seemingly started to switch from "I'll just go off and do my work on a branch and then we'll integrate" to "I don't trust anything anybody else has written and we'll review every single line".
I worked at Google for 10 years and when I emerged from there everyone had switched to code review, even small startups.
FWIW I see advantages and disadvantages to both approaches. But I don't think GitHub is to blame? Google clearly has an intrinsic interest in making sure things don't blow up $$ production, and are willing to sacrifice velocity all over the place to make sure of that. Same with projects like the Linux kernel, or GCC or LLVM or whatever. But...
(If anything, Git makes working on longer running feature branches a lot easier, and the whole code/pull review process made more sense with centralized systems like Perforce, etc. or systems like CVS or SVN that had terrible merge-on-merge support)
Based on my own experience I am quite sure that code review doesn't sacrifice velocity, it enables it. Unreviewed development has no way to ensure everyone is pulling in the same direction.
Totally agree! Code reviews are not only for 'making sure things don't blow up $$ in production.' If your team doesn't use pair programming, code reviews are the best opportunity to share knowledge and align vision and values across the team.
If you feel like code review conversations are taking too long and affecting your cycle time, then you can use the tool I created: https://pullpo.io to have these conversations on ephemeral bidirectional GitHub-Slack channels.
If you feel like code review conversations are taking too long and affecting your cycle time, then you can use the tool I created: https://pullpo.io to have these conversations on ephemeral bidirectional GitHub-Slack channels.
It really, really, depends.
I love git. I've used it for my personal projects, used it for work, used it for projects ive lead. Small teams, larger teams, single person. Occasional contributors, fulltime contributors, so on, all included.
I have never felt the urge to try anything else - so I'm as biased as I can be.
I think GitHub went down hill so much that I get a little angry every time I have to use it. It used to be snappy - links you click used to actually load. Now, somehow, they managed to make it a single page app that stays on one view even when it has already loaded another -- its very strange. I go to issues, click new issue, the URL changes, the loading bar finishes -- and nothing. Just still the issues view. A few seconds later it changes.
I cant push to [email protected]:lionkor/my-new-repo to create a repo (GitLab allows this, and it makes working a lot smoother).
The PR view is horrendous. GitHub actions are nice, but not great. I prefer GitLab here, too.
Then again - nobody is forcing me to use GitHub, so I dont have an issue with it. If it becomes more shit, people will migrate, and it will slowly die.
Tools which assume github as the primary git repo host are faulty by design, though.
I have never felt the urge to try anything else - so I'm as biased as I can be.
I think GitHub went down hill so much that I get a little angry every time I have to use it. It used to be snappy - links you click used to actually load. Now, somehow, they managed to make it a single page app that stays on one view even when it has already loaded another -- its very strange. I go to issues, click new issue, the URL changes, the loading bar finishes -- and nothing. Just still the issues view. A few seconds later it changes.
I cant push to [email protected]:lionkor/my-new-repo to create a repo (GitLab allows this, and it makes working a lot smoother).
The PR view is horrendous. GitHub actions are nice, but not great. I prefer GitLab here, too.
Then again - nobody is forcing me to use GitHub, so I dont have an issue with it. If it becomes more shit, people will migrate, and it will slowly die.
Tools which assume github as the primary git repo host are faulty by design, though.
> If it becomes more shit, people will migrate, and it will slowly die.
You might be surprised how vendor lock-in can prevent many projects from migrating in the future. If you’ve not yet migrated, it would be wise to stay away from Microsoft-GitHub-only features.
You might be surprised how vendor lock-in can prevent many projects from migrating in the future. If you’ve not yet migrated, it would be wise to stay away from Microsoft-GitHub-only features.
I love that the Crystal Programming language build system (Shards) supports not just all the git-based solutions, but also Fossil and Mercurial. Giving programmers the flexibility to choose other solutions if they want to is great, even if they aren't exercised regularly.
absolutely agree. Github has this nice thing. They keep trying to protect you. An unintended side effect these protections make it easier and easier for you to do things with other Microsoft products. Well of course, why would anyone have a problem with that? And at some point if you decide github is not for you - the price is too high, your account is frozen or whatever - you will find that getting out of github is extremely difficult. If you believe there are plenty of good alternatives why not use one now?
Nothing on the internet is free. You may think you are getting something for free, but you have to ask yourself how the company giving you that freebee makes its money? Qui bono && quid bonum? Lock-in anyone?
Nothing on the internet is free. You may think you are getting something for free, but you have to ask yourself how the company giving you that freebee makes its money? Qui bono && quid bonum? Lock-in anyone?
> This is largely because of GitHub’s popularity and in spite of git’s poor UX.
That's a big deal. Git's CLI is really powerful, but it has pretty poor GUIs. I use Sourcetree[0] a lot. It is sufficient, but also pretty damn buggy, and doesn't really give me access to some of the more powerful CLI features, so I sometimes need to go into the CLI.
I have tried other Git GUIs (I am deliberately not naming names), and have found them to be fairly pretty, but also worthless. A pretty UI is great, but it also needs to have some meat on its bones.
[0] https://www.sourcetreeapp.com
That's a big deal. Git's CLI is really powerful, but it has pretty poor GUIs. I use Sourcetree[0] a lot. It is sufficient, but also pretty damn buggy, and doesn't really give me access to some of the more powerful CLI features, so I sometimes need to go into the CLI.
I have tried other Git GUIs (I am deliberately not naming names), and have found them to be fairly pretty, but also worthless. A pretty UI is great, but it also needs to have some meat on its bones.
[0] https://www.sourcetreeapp.com
The Github Desktop is criminally underrated in my opinion https://desktop.github.com/
Yes, it's pretty underfeatured and lacks all the advanced features, but I consider that a plus. It's great at checking out and syncing branches, and doing (partial) commits. It does the basics really well IMHO.
I think the hard part with GUI git apps is that all the advanced functionality is... advanced and is difficult to translate into a gUI.
Yes, it's pretty underfeatured and lacks all the advanced features, but I consider that a plus. It's great at checking out and syncing branches, and doing (partial) commits. It does the basics really well IMHO.
I think the hard part with GUI git apps is that all the advanced functionality is... advanced and is difficult to translate into a gUI.
> advanced and is difficult to translate into a gUI.
This is true, so it may be difficult to find a free GUI that will do it.
However, the paid ones are worse than the free one.
This is true, so it may be difficult to find a free GUI that will do it.
However, the paid ones are worse than the free one.
lazygit (sadly on GitHub: https://github.com/jesseduffield/lazygit) offers a wonderful TUI for Git that has helped me on a number of occasions visualize Git when needed. The bonus of the TUI is that it works well with upterm/tmate for pair programming.
Don't like GitHub? Just self-host. Even projects like ReactOS, RedoxOS, wireguard are doing it for years.
Unless you want to contact the CEO of GitHub when your project goes down again or the CI stops working like it did weeks ago.
Unless you want to contact the CEO of GitHub when your project goes down again or the CI stops working like it did weeks ago.
The "call to arms" is great but doesn't really offer any ideas.
There are alternatives already and if they are not getting enough use, there must be reasons. What are they?
I don't enjoy this in PRs either. Someone says "this is not good" or "let's not do X". Great, what do you propose instead?
The proposal here is to "let's not not do something" but that's not strong enough, especially if the author is not a strong figure.
It also makes me question, did git happen because people in general hated svn? There were lots of haters of svn and cvs and the others but it didn't happen until Linus had a clear vision of what was missing and what would replace the existing tools
I believe that's how change happens.. not because people preach we should not not do something but they at least suggest something concrete and/or create something to fill the void as best as they can
There are alternatives already and if they are not getting enough use, there must be reasons. What are they?
I don't enjoy this in PRs either. Someone says "this is not good" or "let's not do X". Great, what do you propose instead?
The proposal here is to "let's not not do something" but that's not strong enough, especially if the author is not a strong figure.
It also makes me question, did git happen because people in general hated svn? There were lots of haters of svn and cvs and the others but it didn't happen until Linus had a clear vision of what was missing and what would replace the existing tools
I believe that's how change happens.. not because people preach we should not not do something but they at least suggest something concrete and/or create something to fill the void as best as they can
> I’d like to see what other tools people can offer. Perhaps a tool that promotes ensemble working to share the problem solving and context with a larger group.
> ...what if a tool could helps teams design software before code is written? Right now all guidance and critique happens after, which requires developers to context switch and redo work.
I remember trying to do some visual design work for GNOME to improve the UX, share some prototypes, ideas, and iterate, but I have a hard time to understand how to work on the platform (I think it was GitLab), and people on the project also expect that I should submit code, finally I give up, maybe I was in the wrong, but that was my short experience with that.
> ...what if a tool could helps teams design software before code is written? Right now all guidance and critique happens after, which requires developers to context switch and redo work.
I remember trying to do some visual design work for GNOME to improve the UX, share some prototypes, ideas, and iterate, but I have a hard time to understand how to work on the platform (I think it was GitLab), and people on the project also expect that I should submit code, finally I give up, maybe I was in the wrong, but that was my short experience with that.
I don't publish at github anymore. I won't do it. I still use my account for bug reports and stuff for projects that host there, that's all.
I'm not one of the old guys, I genuinely do not like email based collaborative workflows, I prefer the web repo paradigm that comes with github and gitea/forgejo, gitlab and the like. It's not ideal but I prefer it. But github is at this point a no go for me due to the fact that they make you agree to terms which essentially allow them carte blanc with your products, including giving them the right to violate your license.
Something ideal for me would be Fossil with RSS feeds for every type of action.
I'm not one of the old guys, I genuinely do not like email based collaborative workflows, I prefer the web repo paradigm that comes with github and gitea/forgejo, gitlab and the like. It's not ideal but I prefer it. But github is at this point a no go for me due to the fact that they make you agree to terms which essentially allow them carte blanc with your products, including giving them the right to violate your license.
Something ideal for me would be Fossil with RSS feeds for every type of action.
Thinking of alternatives to Git reminds me the different ways to install Python packages, all the different JS frameworks. God, please don't let there be 4-7 semi popular different ways of source control. There's already so much to learn.
> While the letter of the law here is still uncertain, I believe that Copilot is violating the spirit of these Copyleft licenses. This is deeply disrespectful code laundering at scale. The inability to control the use of your source code is hardly in keeping with the place “where open source communities live”
You think openAI isnt going to scan every line of code on the internet no matter what?
Where ever you host your good, be it gitlab or codeberg or bitbucket, openAI is for sure going to be training on that.
What's going to stop them is regulations, and nothing else.
You think openAI isnt going to scan every line of code on the internet no matter what?
Where ever you host your good, be it gitlab or codeberg or bitbucket, openAI is for sure going to be training on that.
What's going to stop them is regulations, and nothing else.
Microsoft GitHub gets the ability retain your entire Git history too for training, including the bits you may have force pushed away. Scanning other code forges wouldn’t give access to the ‘complete’ history of a project.
They can do the same by cloning the repo
Not if you have rewritten this history. It's possible they have an old copy, but cloning isn't going to have deleted or unrewritten commits. What do you think folks do when say an API key is published in the repository? Delete the whole repo to get a clean history? However, there's nothing that stops Microsoft GitHub from just _holding onto_ that data even if you delete it because you gave that data to them.
I mean why do you rewrite history? Its either because of a typo or editing commits.
I doubt its very important for ai training.
API keys/other secrets, implementations of features that ultimately were dropped are two examples. The former has security/privacy implications with a closed platform owned by an adversarial entity, Microsoft. The latter might leak info on future plans or how a senior corrected a junior then squashed which could be very valuable for training that others would not have access to.
The nice thing about GitHub/git is you always have a full local copy of the repo as well. Having a dominant website seems less dangerous for this reason.
SvnHub would have been very scary on the other hand.
SvnHub would have been very scary on the other hand.
Is this a good time to mention CodeBerg?
I know the name is supposed to invoke "iceberg" but my brain thinks "fatberg" every time.
Codeberg is mentioned in the article as one of the alternatives
I currently have my portfolio/cv on it. It's simple and great.
> git remains dominant despite it being complex because it’s not in the interest of GitHub and most of GitHub’s competitors to support anything else.
It seems like if there was a competitive advantage to be found in another VCS it would be a large opportunity for a competitor to support and promote that alternative. Git certainly has many downsides but I am not sure a different system is an overall better proposition than git at this point. If it was, I would think we would see more investment there.
It seems like if there was a competitive advantage to be found in another VCS it would be a large opportunity for a competitor to support and promote that alternative. Git certainly has many downsides but I am not sure a different system is an overall better proposition than git at this point. If it was, I would think we would see more investment there.
devault had a similar post like this a little over a year ago[1]. if only we were all floss practitioners - seemingly, maybe naively, the most ethical ground in software
been meaning to set up a stagit instance but it's really not my domain - i should try reading the man page for starters
1: https://drewdevault.com/2022/03/29/free-software-free-infras...
been meaning to set up a stagit instance but it's really not my domain - i should try reading the man page for starters
1: https://drewdevault.com/2022/03/29/free-software-free-infras...
I really appreciate his mentioning of FOSS communications as well. It’s unacceptable how many projects are locked solely into Discord or Slack.
Check out https://jamsync.dev if you're interested a non-git alternative
I can agree that git's "monopoly" is kinda ugly and it'd be nice if GitHub allowed something else under the hood.
But I'd rather not have to use some half-baked / not popular or even worse - have to use a few platforms for projects hosting.
GitHub is really helpful and makes life (and work) easier. It's been built on dev. experiences and needs across whole industry
But I'd rather not have to use some half-baked / not popular or even worse - have to use a few platforms for projects hosting.
GitHub is really helpful and makes life (and work) easier. It's been built on dev. experiences and needs across whole industry
Really glad to see I am not the only one who is gravely concerned, especially in the new-world of "cancel culture".
Even being willfully blind to the danger our dependency on github portends, Microsoft's purchase of github should be enough reason for the development community to diversify.
This is very very well written.
Even being willfully blind to the danger our dependency on github portends, Microsoft's purchase of github should be enough reason for the development community to diversify.
This is very very well written.
Maybe it's just my bubble, but from the projects I've been working on there last 5 years, most gitops is migrating to GitLab.
I do keep using GitHub for small personal projects though. The interface to create something very simple, it's just more straightforward on GitHub. But, for everything else - specially at work- it's GitLab.
I do keep using GitHub for small personal projects though. The interface to create something very simple, it's just more straightforward on GitHub. But, for everything else - specially at work- it's GitLab.
i really liked google code, particularly because it supported mercurial, and worked pretty well. typically, google closed it.
I wish GitHub someday will support Pijul.
https://pijul.org/
https://pijul.org/
You should wish it could be self-hostable and _not_ require a proprietary account like Microsoft GitHub.
(I wish github does not become one but sadly gitlab is beset with constant pain)
- no proper communication - unclear future plan - poor documentation
See for example
https://gitlab.com/gitlab-org/gitlab/-/issues/380872
- no proper communication - unclear future plan - poor documentation
See for example
https://gitlab.com/gitlab-org/gitlab/-/issues/380872
I've looked at your example, but all I'm seeing is a deprecation process for a feature with an alternative workflow, and all sorts of warnings, a timeline and even a shifting timeline to allow users to update.
Can you specify exactly what you find lacking? Is it the fact that there is a breaking change?
I'm not familiar with this case, but from a glance I see proper communication, a clear future plan and adequate documentation. I'm not affiliated with gitlab btw.
Can you specify exactly what you find lacking? Is it the fact that there is a breaking change?
I'm not familiar with this case, but from a glance I see proper communication, a clear future plan and adequate documentation. I'm not affiliated with gitlab btw.
If one runs the command until last week or so it exited (with failure) but pointed out that it is deprecated and provided a link to https://docs.gitlab.com/runner/register/index.html
finally (after digging into stackexchange and gitlab issue) one needs to run the command without
gitlab-runner register
finally (after digging into stackexchange and gitlab issue) one needs to run the command without
--non-interactive
That's the thing though! They announced one of the most critical part of the runners (the token auth) to be deprecated for months before the replacement was even available for teams to switch to. Very bizarre
I feel like if gitlab were worse it would be less frustrating because my expectations would be considerably lower.
Use gogs.
I'm currently looking at alternatives for self-hosting. Do you prefer gogs to gitea? why, if so?
I prefer projects maintained by single or few developers. Gogs seems to be that kind of project. Gitea is maintained by some kind of community. Other than that, I think they don't differ that much. Gitea is Gogs fork after all.
I’ve been using gitea for years and I love it. I heard about gogs after migrating to gitea, but it seems like gitea is mostly an improved gogs.
It's not the only standard. It's just a centralized, single-point-of-failure, which is in some ways anathema to git in itself - which is meant to be distributed by default.
A simple bare git repository can be had on any server and it's moderately easy to manage. There's sr.ht and Gitlab and on and on!
A simple bare git repository can be had on any server and it's moderately easy to manage. There's sr.ht and Gitlab and on and on!
I want some spare git web interface with ability to store my helloworlds somewhere online. Github was perfect before MS and now it became slightly annoying. Sourcehat requires me to pay, and I am not ready to learn any other VCS yet. Any alternatives for me?
If you look at the git project commit history, you'll notice quite a few of the top contributors are GitHub staff. Personally, I've played with the other options, they're mostly just half-baked clones of GitHub so why bother.
I'm not an experienced Dev if you could even class me as one but for my personal projects I use fossil. I'm not a power user of fossil and I'm not using it for anything distributed but I like it.
GitHub is popular enough that I suspect it won't be a competitor that dethrones them, but rather they will implode from within. The copilot controversy is already steering things that way.
I really really like SourceHut but it's lack of Pull Requests (and to some degree Organizations) are the only blockers I have for using it for both personal and work purposes.
Use Gerrit! It is much better. But it requires that you host it yourself, AFAIK. It is pretty straightforward, and just sits there once you get it running.
Look into decentralized approaches like Mango and Radicle.
https://github.com/axic/mango#get-started is some uh-huh
---
https://app.radicle.xyz/seeds/seed.radicle.xyz/rad:z3trNYnLW...
seems like a much more reasonable peer-to-peer setup, although my mental model of peer-to-peer setups is they're fine until they stop becoming popular and then it's just you on your island waiting for some obscure project's seeder to come back online
Prerequisites:
an Ethereum node
an IPFS node
git and node.js environment
---
https://app.radicle.xyz/seeds/seed.radicle.xyz/rad:z3trNYnLW...
seems like a much more reasonable peer-to-peer setup, although my mental model of peer-to-peer setups is they're fine until they stop becoming popular and then it's just you on your island waiting for some obscure project's seeder to come back online
Gitea is great. The recent update that made email notifications like GitHub's by allowing you to reply to Issues comments is beautiful.
>GitHub’s job is to make Microsoft money
This is my concern, if the US Gov had **lls, you would force Microsoft spin Github off into a non-profit company.
Already things have been added to Github that most developers of "Open" Source do not like. Time for github to be made independent and run from a foundation like the *BSDs
This is my concern, if the US Gov had **lls, you would force Microsoft spin Github off into a non-profit company.
Already things have been added to Github that most developers of "Open" Source do not like. Time for github to be made independent and run from a foundation like the *BSDs
Outside of the obvious fact that the US government has no power to arbitrarily take away property because "most people don't like it" (a dubious claim by the way), it's not like an independent foundation will necessarily improve things. Point in case: that horrendous GNU Savannah thing.
You wrote:
Point in case: that horrendous GNU Savannah thing.
What's wrong with the non-GNU side? The hosting requirements look pretty reasonable to me: https://savannah.nongnu.org/register/requirements.php
What's wrong with the non-GNU side? The hosting requirements look pretty reasonable to me: https://savannah.nongnu.org/register/requirements.php
Have you ever used it? The UI is like a bad copy of SourceForge anno 1998 (in fact, IIRC it's based on a very old copy of the SourgeForge code). Savannah is pretty much the embodiment of "open source people can't design UIs if they lives depended on it".
Also: some of those policies are ridiculous. "We require the “or any later version” formulation for the GNU GPL, GNU AGPL, and GNU LGPL." It could not host the most widely used free software on the planet: Linux.
Also: some of those policies are ridiculous. "We require the “or any later version” formulation for the GNU GPL, GNU AGPL, and GNU LGPL." It could not host the most widely used free software on the planet: Linux.
The US government is interested in making sure US companies get as big as possible, why would they hamstring them?
Do you think they're out there shooting people in the Middle East so that Middle Eastern oil companies can make more money or so that the American ones can?
Do you think they're out there shooting people in the Middle East so that Middle Eastern oil companies can make more money or so that the American ones can?
I think regulation is a little more complicated than that.
There is a vast system of interests, but I don't agree that overall incentives are to make US companies get as big as possible. They lose competitiveness at some point.
Middle East is not relevant.
Github not being part of Microsoft could be better for the overall economy. Consider the development of the World Wide Web. If you consider Github and aspects of Github as a network and communication protocol, it would be better in the long term to decentralize control.
There is a vast system of interests, but I don't agree that overall incentives are to make US companies get as big as possible. They lose competitiveness at some point.
Middle East is not relevant.
Github not being part of Microsoft could be better for the overall economy. Consider the development of the World Wide Web. If you consider Github and aspects of Github as a network and communication protocol, it would be better in the long term to decentralize control.
IMO the US government has a big interest in trying to get American companies as big as possible, and to keep them in the US. Or maybe you can point out some things that the government has done (recently) to show the opposite?
What does Github use for version control? Github? Is there a github github?
Cool. Here's how to do it:
1. Migrate off of GitHub.
That's it, that's the whole process.
1. Migrate off of GitHub.
That's it, that's the whole process.
Just want to say I love this website's animated logo.
Fortunately he's posted the source on github https://github.com/edwardloveall/portfolio/blob/main/app/vie...
The writer uses macOS. If github is 'only' option so it Apple becoming these days. From iMessages (blue/green tick) social pressure across the world.
And the writer hosts the source for his blog on github https://github.com/edwardloveall/portfolio
launchpad!!
https://launchpad.net
"We risk leaving brilliant developers behind who don’t work well with GitHub’s paradigms. We risk being stuck with our old, technical mistakes because the underlying technology never changes. We risk losing control over our tools because they’re not actually our tools."
That ship sailed 15 years ago. Our tech has already ossified around shitty backwards designs. Every piece of technology today now relies on 1990s-era World Wide Web tech. You can't do anything over the internet that doesn't pass through an HTTPS connection on port 443 of the tcp protocol, increasingly using QUIC, a userland-only application-specific tcp/ip-stack replacing the operating system's, because everyone is too lazy to move "web standards" into the operating system. "It works for my app" is now good enough for the industry, and all is justified by the cries of "oh but middleboxes". Apparently change is impossible because it would require effort. The tech world is now political.
"The more you use and rely on GitHub, the more difficult it becomes to find and use alternatives"
No, it's easy to find alternatives, there are 20 or more. It's easy to switch.
"This PR-centric way of working can also create a bazaar-style culture of low-trust. Low-trust can be an important part of the software development process. Open-source contributions from unknown developers come to mind, or perhaps a legal team needs to sign off on a change.
But low-trust is the opposite of what I believe most smaller teams want; even teams in big organizations. In those environments you want to encourage autonomy which requires high-trust."
Most organizations and teams are really shitty at organizing their work, communicating, and working across teams/BUs. The "high-trust" model is actively detrimental to both the individual team and larger efforts. The bazaar model is superior. Yes, people want to live in silos, but it's actively detrimental and should be abandoned.
"The Pull Request workflow is so dominant now that it’s considered the default path for code to permanently enter into a repository."
Pull Requests are not mandatory, you don't have to use them. Just because your team uses them doesn't mean they have to. But they have become a cultural trope, and culture is the hardest thing in the universe to change. You could throw the baby out with the bathwater, or you could lead by example, and show people a different way to work. Getting rid of GitHub won't stop other cultural problems from cropping up.
"GitHub is what most people use because it makes the complexities of git easier. git remains dominant despite it being complex because it’s not in the interest of GitHub and most of GitHub’s competitors to support anything else."
Yeah, again, culture problem, not technology problem. Want something better? Make it. The alternatives that exist clearly aren't advantageous enough for people to switch.
"We should instead be supporting platforms that seek to do no harm."
Again, there are alternatives to GitHub, go and use them.
But for what it's worth, all of this concern trolling doesn't amount to much. Want to switch? Switch. Don't want to? Don't. This isn't something to spend more than 5 minutes thinking about. When you have a problem, deal with it; until you have a problem, stop worrying.
That ship sailed 15 years ago. Our tech has already ossified around shitty backwards designs. Every piece of technology today now relies on 1990s-era World Wide Web tech. You can't do anything over the internet that doesn't pass through an HTTPS connection on port 443 of the tcp protocol, increasingly using QUIC, a userland-only application-specific tcp/ip-stack replacing the operating system's, because everyone is too lazy to move "web standards" into the operating system. "It works for my app" is now good enough for the industry, and all is justified by the cries of "oh but middleboxes". Apparently change is impossible because it would require effort. The tech world is now political.
"The more you use and rely on GitHub, the more difficult it becomes to find and use alternatives"
No, it's easy to find alternatives, there are 20 or more. It's easy to switch.
"This PR-centric way of working can also create a bazaar-style culture of low-trust. Low-trust can be an important part of the software development process. Open-source contributions from unknown developers come to mind, or perhaps a legal team needs to sign off on a change.
But low-trust is the opposite of what I believe most smaller teams want; even teams in big organizations. In those environments you want to encourage autonomy which requires high-trust."
Most organizations and teams are really shitty at organizing their work, communicating, and working across teams/BUs. The "high-trust" model is actively detrimental to both the individual team and larger efforts. The bazaar model is superior. Yes, people want to live in silos, but it's actively detrimental and should be abandoned.
"The Pull Request workflow is so dominant now that it’s considered the default path for code to permanently enter into a repository."
Pull Requests are not mandatory, you don't have to use them. Just because your team uses them doesn't mean they have to. But they have become a cultural trope, and culture is the hardest thing in the universe to change. You could throw the baby out with the bathwater, or you could lead by example, and show people a different way to work. Getting rid of GitHub won't stop other cultural problems from cropping up.
"GitHub is what most people use because it makes the complexities of git easier. git remains dominant despite it being complex because it’s not in the interest of GitHub and most of GitHub’s competitors to support anything else."
Yeah, again, culture problem, not technology problem. Want something better? Make it. The alternatives that exist clearly aren't advantageous enough for people to switch.
"We should instead be supporting platforms that seek to do no harm."
Again, there are alternatives to GitHub, go and use them.
But for what it's worth, all of this concern trolling doesn't amount to much. Want to switch? Switch. Don't want to? Don't. This isn't something to spend more than 5 minutes thinking about. When you have a problem, deal with it; until you have a problem, stop worrying.
Wannabe Github competitors have two major problems:
1) it's free and it's hard to make a profit competing with free. Never mind that it isn't really free. It's free enough that making a profit doing the same thing just is not a great plan.
2) it quite literally has close to 100% of all oss projects in existence on their platform. There are no alternative platforms that have anywhere near close to the same network of developers, companies, etc. Being part of that network provides discoverability, easy access to other developers, etc. People care about Github stars. Nobody cares about whatever the Gitlab equivalent is to that.
Feature wise, Github is a commodity. Hosting projects doesn't cost a whole lot if you think about it. Most git projects aren't very big. They don't get a lot of traffic. Etc. So the real cost of hosting a project is pretty low to begin with. There are of course some bigger projects that would generate a bit of traffic. But on average, it's not much.
Gitlab and others have proved long ago that it's not that hard to replicate what Github did. And that in turn prompted Github to offer it for free because they recognized it was a race to the bottom. Making private projects free entrenched them as the #1 company in this space. And of course they are not for free if you are running big enterprise organizations on them. Sponsoring a lot of tiny OSS projects, libraries, struggling startups, etc. with that revenue isn't that expensive. And it makes sales to companies really easy. Because they and anyone they hire are likely already on Github anyway.
It's of course not that hard to roll your own clone that does more or less the same. Lots of companies have actually done that and some of them have a quite nice business offering that as a SAAS service to companies not interested in using Github for various reasons. So, the added value of doing that some more only diminishes its value. To the point that it's a fairly pointless thing to do. Even if you do it well, it's basically just yet another Github clone without a network.
People that argue the social network doesn't matter are missing the point: it's the thing that matters most. Software development is a social process. And a social network without any members is just not that interesting. And not getting that you are developing and competing with a social network is not a great premise for coming up with something better.
Hypothetically, if somebody were interested in such a thing, imitating what Mastodon is doing to Twitter wouldn't be a bad idea. Git is decentralized by design. But Github isn't, which is in a way the biggest problem people seem to have with it. So fix that problem. The fix is not replacing it with another centralized social network. That would be moving the problem, not solving it. Of course the trick is finding a business model to fund that.
1) it's free and it's hard to make a profit competing with free. Never mind that it isn't really free. It's free enough that making a profit doing the same thing just is not a great plan.
2) it quite literally has close to 100% of all oss projects in existence on their platform. There are no alternative platforms that have anywhere near close to the same network of developers, companies, etc. Being part of that network provides discoverability, easy access to other developers, etc. People care about Github stars. Nobody cares about whatever the Gitlab equivalent is to that.
Feature wise, Github is a commodity. Hosting projects doesn't cost a whole lot if you think about it. Most git projects aren't very big. They don't get a lot of traffic. Etc. So the real cost of hosting a project is pretty low to begin with. There are of course some bigger projects that would generate a bit of traffic. But on average, it's not much.
Gitlab and others have proved long ago that it's not that hard to replicate what Github did. And that in turn prompted Github to offer it for free because they recognized it was a race to the bottom. Making private projects free entrenched them as the #1 company in this space. And of course they are not for free if you are running big enterprise organizations on them. Sponsoring a lot of tiny OSS projects, libraries, struggling startups, etc. with that revenue isn't that expensive. And it makes sales to companies really easy. Because they and anyone they hire are likely already on Github anyway.
It's of course not that hard to roll your own clone that does more or less the same. Lots of companies have actually done that and some of them have a quite nice business offering that as a SAAS service to companies not interested in using Github for various reasons. So, the added value of doing that some more only diminishes its value. To the point that it's a fairly pointless thing to do. Even if you do it well, it's basically just yet another Github clone without a network.
People that argue the social network doesn't matter are missing the point: it's the thing that matters most. Software development is a social process. And a social network without any members is just not that interesting. And not getting that you are developing and competing with a social network is not a great premise for coming up with something better.
Hypothetically, if somebody were interested in such a thing, imitating what Mastodon is doing to Twitter wouldn't be a bad idea. Git is decentralized by design. But Github isn't, which is in a way the biggest problem people seem to have with it. So fix that problem. The fix is not replacing it with another centralized social network. That would be moving the problem, not solving it. Of course the trick is finding a business model to fund that.
I agree that the social aspect "where everyone is" is important, but crucially it's also not a fixed state. When GitHub started, SourceForge was where everything was. Over the next 15 years something else may displace GitHub, especially if there is a concerted, conscious effort to do so. Then again, it may not.
Sourceforge lacked the social network status. It was just a place where people put their source code and binaries. But there was not a lot of interaction on the platform.
To kick off that effort to replace Github, lots of money would be needed and some incentive to get people off Github. I.e. a busines model and some added value. Hard to see where that would come from right now. Github did not displace source forge by doing the same but by doing something better.
To kick off that effort to replace Github, lots of money would be needed and some incentive to get people off Github. I.e. a busines model and some added value. Hard to see where that would come from right now. Github did not displace source forge by doing the same but by doing something better.
Git is far from an ideal solution, but it has emerged as the standard way to manage version control in a software project, and we benefit from there being a standard. Version control is the first barrier to entry in starting on a new project, so having an industry standard for version control benefits everyone: open source projects get more contributors, companies don't have to train new hires on their system, and employees have one fewer barrier blocking them from specific jobs.
Could we have standardized on a better system? Certainly. But launching a competing standard at this point isn't going to make things better, the best case scenario is that it fragments the industry.