Let's make sure GitHub doesn't become the only option
blog.edwardloveall.com
blog.edwardloveall.com
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.
But Git is pretty good, so it will take something vastly better to replace it.
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)
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.
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.
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
That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
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.
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.
Edit: And Visual Source Safe
I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
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 don't believe any version control system achieved as deep industry penetration as git has.
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
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)
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.
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.
Now, if you go back to the mid '80s and earlier, version control was rare.
yes ... how did you know we used visual source safe?
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).
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.
Git is fine, but honestly, my favorite of the several I've used over the years is still svn.
Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it.
Don’t confuse inertia with goodness.
Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are 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.
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.
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?)
Worked at another company circa 2015 with around 80k employees (not sure how many engineers) that used git + cgit + Jenkins + JIRA.
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 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.
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.
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.
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.
[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/
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.
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.
There is no provision for a fair shake, special categories for new entrants, or anything similar.
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.
> 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.
> 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.
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 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 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?
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.
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."
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.
Likewise the standard DB may be Postgres.
Others exist but they’re certainly not the recommended defaults you find people giving out nowadays.
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.
https://survey.stackoverflow.co/2022/#most-popular-technolog...
VSCode is overwhelming at a staggering 74%. ;P
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. ;)
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? :)
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.
> 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.
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.
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/
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.
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.
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.
Also add the cloud providers
AWS CodeCommit
GCP Cloud Source Repositories
Azure Repos
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?
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...
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 user@rsync.net "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."
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.
We've been self hosting it in our company for few years and it's been a good experience so far.
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.
That ticket was still open after 7 years.
Even TeamCity had that functionality.
That's when they lost my $.
If something as fragile and arcane as TeamCity has this then that reflects very poorly on CircleCI
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.
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.
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
GitHub has a feature called Maintenance Mode, but its for enterprise customers and doesnt do what you want. Probably hallucinated the rest.
[0] - https://about.gitlab.com/blog/2023/05/01/how-to-build-reusab...
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.
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.
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.
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.
> Effective June 1, 2021: Phabricator is no longer actively maintained.
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.
* 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.
Everything flows.
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.
- 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.
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.
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.
A recent example from a mid level dev:
"I'm gonna branch from the github repository" - when the repository is self hosted
Github != Git
If that keeps up you can just call your alternative repo storage system GitHub 2.0 or GitHub Enterprise or something.
Docker too. ('a docker')
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?
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.
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.
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.
> 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 ...
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)
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.
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 git@github.com: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.
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.
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?
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.
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.
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.
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.
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
> ...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'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.
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.
SvnHub would have been very scary on the other hand.
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.
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...
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
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.
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.
- no proper communication - unclear future plan - poor documentation
See for example
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.
gitlab-runner register
finally (after digging into stackexchange and gitlab issue) one needs to run the command without
--non-interactive
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!
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
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
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?
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.
What's wrong with the non-GNU side? The hosting requirements look pretty reasonable to me: https://savannah.nongnu.org/register/requirements.php
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.
1. Migrate off of GitHub.
That's it, that's the whole process.
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.
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.
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.