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 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.
documentation pages that once again stated the obvious. No difference at all. Then you rerun the command - same bounce out. No clue. The docs linked at the URL still say to use the --registration-token.
finally (after digging into stackexchange and gitlab issue) one needs to run the command without
--non-interactive
No where in the documentation it (until last week) that this should be removed for registering a runner as of today (last few months).
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 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.
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.
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 :)
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.
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.
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
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.
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.
So should morals never enter any argument at all? I don't even agree with their stance on this particular topic, but this dismissive complaining about "virtue signalling" is considerably more egregious than listing reasons you don't like GitHub, which happens to include a moral argument.
Does not using Github change anything about ICE or the contract? Pretty sure not. So what does proclaiming it even do? Its nothing but self-service. Plus its red vs blue US politics, which is also not very pleasant to know about.
Like I mentioned, I don't agree with their position so I'm not going to defend it. I am only defending that it's a legitimate argument to make and that it can't just be dismissed as "annoying virtue signalling" and "screaming". You can do this with almost any argument if you try hard enough.
That they are annoyed by the implication that a company's contracts with a governmental agency should have any bearing on whether one should consider using their product, I would have thought.
Which is always a funny criticism of Github because I'd wager the people who are against ICE want the immigration system to be faster and more streamlined. I'm guessing custom software is a big part of managing encounters, asylum claims, court appearances, and of course deportations. Removing tools from that Agency would make that system worse, and therefore slower for the people the complainants seem to support (immigrants).
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.
> 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.
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.
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.
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.
> 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.
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
While I do worry about github, I disagree that the dominance of git is a problem. At some point every industry grows up and standardizes on something, anything, because any standard is better than no standard.
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.
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.
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.
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
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.
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.
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.
- 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
The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.)
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
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)
> 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.
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.
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.
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).
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.
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?
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.
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.
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?)
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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.
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 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.
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'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 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?
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.
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."
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.
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. ;)
> 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? :)
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.
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.
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).
> 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.
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?
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.
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.
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.
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.
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.
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.
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
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?
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.
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?
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.
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.
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:
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):
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.
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.
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?
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 emunday@atlassian.com
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...
"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:
"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 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.
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
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!
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.
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.
> 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.
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.
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.
"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)
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.
“ 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.
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.
308 comments
[ 2.9 ms ] story [ 249 ms ] thread- no proper communication - unclear future plan - poor documentation
See for example
https://gitlab.com/gitlab-org/gitlab/-/issues/380872
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.
finally (after digging into stackexchange and gitlab issue) one needs to run the command without
No where in the documentation it (until last week) that this should be removed for registering a runner as of today (last few months).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.
[1]: https://en.wikipedia.org/wiki/Generic_trademark
Docker too. ('a docker')
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...
That sentence is halfway down the page.
That they are annoyed by the implication that a company's contracts with a governmental agency should have any bearing on whether one should consider using their product, I would have thought.
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.
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
The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.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.
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.
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.
* 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.
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.
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.
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?
https://jira.atlassian.com/browse/BCLOUD-15317
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:
Remember, also, the existence of "git annex":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.
---
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
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!
SvnHub would have been very scary on the other hand.
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
> 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 ...
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
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.
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.
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.
https://pijul.org/
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.