I personally think that Fossil is a good example that's extant and used in serious projects. There's that one called pijul which also looks good in theory, but I haven't worked with it. I think version control in general is a little broken before you even get to the software level, but those are two projects tackling some of the problems. And Fossil, I think, is more suited to the scale most people operate on.
There is definately scope for a beginner friendly UI/UX. Julia Evans has a post lately about confusing aspect of git. Ability to version control large files (like git-lfs) would be a nice addition.
Many tried, few succeded.
SVN - client-server principle, but bad at merging branches
mercurial - one of the competitors after the linix kernel devs searched a new version control system, its users die out, since git is more popular, very similar to git
bazaar - mostly used for ubuntu, since launchpad is only providing bazaar as vcs
I'm sure we can, the question is, can we make an alternative to GitHub? I wouldn't be surprised if there are already several better ones, but I've never looked, because I already know Git, and my chances of convincing anyone to use a better one seem low, and they rarely seem to have as big of an ecosystem.
If it doesn't have multiple clouds providers with pull requests, and at least one of those clouds providers isn't a megacorp, it probably won't be the safe boring choice, unless it's fully P2P.
It needs to be packaged in distros, have GUI integrations, etc.
Fossil looks really cool, I really like how they integrate the wikis and issues. But I don't know anyone who uses it, and the cloud providers seem to be smaller "Could go away any time" companies.
I've never really explored any other VCSes, because none ever seem like they're going to be serious competitors.
I'd be more interested in enhancing Git, but it seems a lot of the most interesting git plugins and extensions aren't updated, like GitTorrent.
> the question is, can we make an alternative to GitHub? I wouldn't be surprised if there are already several better ones, but I've never looked, because I already know Git
¿Que?
If you're wondering whether we can make something better than GitHub, there's dozens of git hosting alternatives that you might like better such as Forgejo and GitLab.
If you're saying "but I already know git", then there's still dozens of alternative hosting sites or methods!
GitHub is the one everyone else uses though, which means you can have everything in one place, so they have the advantage.
There are others that are almost as good, I suppose what I should have said is "Can we make something better than GitHub for the hypothetical better non-git VCS", since without that it's hard to imagine using anything but Git.
Pretty sure alternative git services are still larger than alternative source control systems, yet OP is asking about alternatives to git which will be even smaller. The whole point is that the person wants to use something else. If your argument is that Microsoft GitHub is the largest and therefore the best, it's circular reasoning and will forever remain that way.
We should all stay on Facebook also if they're the best because everyone's on Facebook and the network effect has benefits; somehow it seems people have more sense than that and we can actually switch to smaller services which are more aligned with what we want
Close to everyone I know is still on Facebook, and I get the impression none of them have any interest in switching, so... I use it too, even though the algorithmic curation stuff is really bad.
I could imagine people switching if someone made another site with some kind of killer app and promoted it with a million dollars of ads, but... At the moment, the only feature the alternatives focus on is usually privacy, which is clearly not enough to make average people switch.
Network effects aren't the only factor that matters, just a really big one for most.
Re: GitHub alternatives, I've been looking at this for a while as I'm keen to not have everything centralised and Microsoft are hardly the most trustworthy...
There are some GithHub-alikes, the most obvious is GitLab which you can also host yourself but all (or at least some of) the extras you get for free with GitHub are behind payment walls.
My current favourite is Codeberg, it uses Forgejo underneath (which is a fork of Gitea itself a fork of Gogs - all of which you can self host). Codeberg is run by a non-profit and are very much aligned with my ideals. They are also slowly adding nice features like their Woodpecker CI.
One that is growing in popularity and is a little less "GitHub-y" is SourceHut (which also has Mercurial support).
The main issue is that GitHub has really cornered the market. They give so much out for free that is difficult for others to compete with and it has become the de-facto place to host your project. This can mean that hosting anywhere other than GitHub will limit discoverability and contributions from people if they don't want to make an account or work out how to deal with whatever forge you are using.
However one thing that is coming that may help alleviate some of that is forge federation which will allow you to interact with various forges from your "home" forge - which hopefully prevents the need to make an account to make PRs or raise issues.
Edit: I see your other comment now, what could a better GitHub be that supports a better-than-git VCS. Well there did used to be places to host Darcs projects like the Darcs Hub but I don't know if some of the newers ones like Pijul or Jujutsu have any forge support yet.
Edit2: Oh it seems Pijul has "The Nest" for hosting.
Good point, we might want to document that. Btw, I've called it "native backend" and "native forge" myself, but maybe those are not the best terms because there are many possible native backends/forges.
For example, our "Piper" backend at Google is a native backend in the sense that it stores all data in its own database. I think the most exciting thing about that backend is that it's cloud-based so users will be able to access each others' commits (e.g. `jj show <commit id from chat>`) without requiring a push.
Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents which she needs to store in a repo... in this case Subversion is a better version-control-system for her documents... Just SVN Update/SVN Commit - nothing more to learn in Subversion...
This is funny because in PR oriented development I started treating commits in the same way as "save" in IDE,
it's just backup of current state with irrelevant commit message. Everything is described at the end of the work in PR's description and squash merged.
Giant PRs that are squashed into one commit are an anti-pattern. Every commit should contain exactly one logical change AND a descriptive commit message.
Unfortunately a good chunk of the industry doesn't have the discipline to do this.
If you have ever worked in a project where there was discipline around committing, you know there is lots of value in doing so (rebasing becomes easier, you unlock the power of bisect, log is actually useful).
when i started out with git i made an alias to immediately do "git add . && git commit -m 'lazy' && git push" to make it easy to always save my work and ensure its on the server too. git pull is easy enough to remember + type, but i could imagine just calling it update
I would imagine git save is commit, and update is pull?
I think they just want to replace some of the words with alternatives that they prefer. Because at some point someone is going to winge that update should be syncronise and not pull, and save should be push and therefore git is the worst.
Then you might be better off with something like Subversion indeed.
Git is distributed, and that means you can't get away from push, pull and fetch, however you name them.
If want you want is a way to avoid making "New New Presentation FINAL 2", then pretty much all features of most source control systems are superfluous.
To me that doesn't mean Git needs fixing, it means it's definitely not the right tool for your job.
If the specific words used are the problem, using aliases is a straightforward way to fix them. If you do it for someone, it will break the possibility of searching for help online though.
Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are professionals, our tools should be powerful for the advanced user, not beginner friendly.
There has been a lot of push to commoditize software engineering. Unfortunately that has resulted in a swarm of people who want developer salaries without the work or expertise.
Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control.
Learning how to use your tools is part of ANY trade.
I disagree. There’s always more that can be learned about anything but we live in a world with finite time and finite resources. So you can either devote time to learning git or you could spend it doing the actual work.
The fact that git is used by experts and professionals is not an excuse for poor UX. The experts and professionals are almost never Git experts or professionals. I use my car every day, that doesn’t make me a mechanic. Having to understand the inner workings of a tool is an indication of poor design, not a gatekeep we should seek to maintain.
I think there are two things being conflated here.
One is: how do you effectively manage changes to a codebase over time? Git has a model that, for day-to-day use, has primitives like "commit", "branch", and "tag". You also have to understand the difference between your working copy, what is staged for commit, and any other commit in history. These, in combination with the operations you can do with them is actually somewhat complex. This is the thing I am saying people need to learn. And people quite often complain about it.
The other is the organization of git's porcelain layer, the arguments and flags each subcommand takes, and how stuff is presented back to the user. I think git stands to make significant improvement here. Be that as it may, the tool exists as it is. So your options are to use a different VCS entirely, use a different frontend, or learn how to use git as-is.
If you choose to use git but deliberately avoid learning e.g. what a rebase is and why it's useful, you are choosing to be an ineffective developer. Could it be better in some ways? Yes, but it isn't.
I don't think the car analogy is particularly compelling. The "primitives" of a car are already much simpler than git's. The fundamental primitives of a car are "go faster" and "go slower", along with some supporting things like managing your headlights, windshield defrosting, wipers, and horn.
While additional tools are being added to cars to make them safer (e.g. a backup cam or collision detection), the complexity of those tools is increasing rapidly which makes them more prone to failure. And a driver is absolutely not excused from causing an accident just because one of these safety tools failed. You still have to know how to safely operate your vehicle in a variety of conditions.
I often heard this argument from people learning LaTeX in academia. It's difficult and I don't have time to study it. From people that spent years to master advanced maths, people that spent years to learn how to build and operate state of the art experimental setups. But for some reason there's never time to learn your software tools.
A tool can be both beginner friendly AND powerful for advanced users.
Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from having a simple and reliable tool fit for purpose of cable clamping.
There is certainly a need for competent and "proper" software engineering that require special tools and detailed training, but I would argue it's niche and filled by people who build the tools themselves.
IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.
> IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.
They're doing brick-laying work until they aren't. Most problems are easy to solve and don't require very much fussing over. The expertise comes in knowing which problems are worth fussing over and which aren't.
Technology is becoming ever more present in our lives, not less.
Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.
> Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.
I fully agree with this observation, but the reality is that this is where things are going.
Software quality is simply not that relevant today for the majority of software. As long as the billing works fine, the management is happy to see your website barely working - screw the quality if the money is coming in anyway.
Such software costs much less and can be built by bricklayers.
Yes, there must be a better solution. Git is (usually) better than the alternatives, but it is far from being good. Especially the discoverability of its features is a mess - arcane command line incantations, magic processes. Sometimes only a prayer helps before running the 12th command you found on stackoverflow in desperation. Once you leave the pull-commit-push-merge-rebase circle, you gotta hope that god helps you, because no one else will (or more like no one else can).
Unless of course you spend time to learn git, but its complexity is closing up to C++. And using a VCS shouldn't require that amount of effort. It should just get out the way (I must admit, git usually gets out of the way, as long as you use only the base commands... but when it gets in the way, that's when the fun starts)
Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before.
Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.
Rust is a fabulous language for refactoring. Strong types and complete matching make it almost completely impossible to miss a spot when making a change
Even though Python is the language I’ve used most, I wouldn’t want to use it for something with a lot of uncertainty and that will suffer many changes. Type systems make it so much easier to change things early on without breaking everything. I’d probably pick F# or similar.
Python certainly lets you change things quickly, because it does not let you automatically enforce any invariants; this is why it lets you get into such extraordinary inconsistent states so easily! I personally could never imagine trying to make a jigsaw out of jelly because "it's v1 and I'll make v2 properly".
The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Also, as others have said in sibling replies, refactoring Python is not fun due to lack of static types (I know it's gotten better).
There are other advantages aside from the static types debate in the other replies. The need for efficient version control systems is a constant and ongoing battle; you can pick the right data structures (for example, Git's issues with large files are more of a data structure problem than one of raw efficiency) but at the end of the day Python will often be behind on raw performance. Rust will hopefully let us embed the Jujutsu libraries inside other languages, something you can only achieve today in Git with something like libgit2. Finally, a lot of the infrastructure we get to use, like nextest and cargo-insta are simply fantastic even if I have my qualms about Cargo.
Most of the developers (some of them being former Mercurial and Git developers) including me generally seem to like it. Based on my own experience, I think it's a pretty excellent choice, but I'd be a bit biased as a die-hard Haskell/C programmer for something fast with types.
I'm not particularly productive in python. The code gets shat out faster but it's a comparatively weak language for capital-P Programming — lack of types means repeating and checking yourself a lot.
I tried this, and I loved it. It works very well with my workflow.
Perhaps the author can explain - when you clone the repo with
jj git clone
It pulls down a branch that is auto generated like pull-(hash)
I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what.
Another way to say it is that everything works great until I have to pull down the repo from another machine - then the branch history is not what I expect. And I just couldn’t make sense of it or get it to square with what I expected.
I actually created a custom GPT and fed it the jj code and documentation to try and get it to explain it to me to no avail. Jj is so good, I’m willing to give up IDE integration with git if I could just crack this nut.
Just echoing Martin, but: if you can show the repository that is causing this, or at least a screenshot (or something) showing what you're seeing and post it on GitHub, one of us should at least be able to help figure out what's going on.
The inner workings of git are not overly complicated. The real problem is git only provides a thin layer on top of the inner workings. It’s not git that needs replacing, (it’s just saving blobs of data) it’s the user interface on top that is confusing. The problem with simplifying the user interface is that abstracting away the complexity is super difficult.
Git feels a lot like pgp to me: somehow we're not managing to make things simple enough for use by the general public, even when you only need a few buttons and input fields.
There's differences, such as that pgp is more complicated under the hood and it being a cryptographic system that needs to be foolproof whereas in git you can nuke and re-clone without data loss most of the time, let alone confidentiality/integrity loss. It just feels very similar in that only expert users properly use it and most people who could make use of it don't bother learning because the interfaces available are such a struggle (beyond basic operations anyway)
Whether it can all be solved with a simpler user interface, or whether it would require a simpler underlying system to be able to make simpler standard operations, is where I'm not sure
Not overly complicated, but super difficult to abstract is somewhat of a contradiction. Maybe the inner workings are complicated, but not complicated to implement right once you understand them.
Git does have one big architectural problem IMO - native unit of storage is a blob, not a diff. Things like rebase, cherry-pick, 3-way merge, etc would be much easier in a world where the storage model was “diffs” instead of “blobs”.
This would have resulted in simpler CLI tools with fewer pitfalls.
The two are interchangeable; a computer can make one from the other. Storing deltas makes common operations slower, as getting file contents requires replaying all the deltas through history.
One of the most amazing things about Fossil is how you can track the history of a file not just backwards, but also forwards, something which is pretty whacky with git.
100% fossil. there has been a few threads.. and always someone points out edge cases that are only to be solved using git.. well i dont think so. you can actually go into the sqlite db and change stuff. i've recently started playing with its server api to direct user feedback from web to fossils ticketing system. it is just mature and feature packed and i honestly hope it will get as much recognition as sqlite someday.
> you can actually go into the sqlite db and change stuff
_Nothing_ history-relevant can be changed via manipulation of the Fossil db. In terms of db records, as opposed to space, the db is about 80-90% a transient cache of data which is generated from the remaining (100% immutable) data. Any changes you make to that transient data will be lost the next time that cache is discarded and rebuilt. A longer explanation can be found at:
As for DVCS, the best one I've used is Darcs: https://darcs.net/ There are some sticky wickets (specifically, exponential-time conflict resolution) that hindered its adoption.
Thankfully, there's Pijul, which is like Darcs but a) solves that problem; and b) is written in Rust! The perfect DVCS, probably! https://pijul.org/
I am not sure if we will ever be able to replace git with anything else. It is so ubiquitous and just "good enough" for most developers, that the pain of switching to a completely new system would far outweight the benefits. Therefore the only solution that I see is a versioning system that is fully backward compatible with git, maybe just a better API layer on top of git. Facebook tried something similar with Sapling.
For a new versioning system we do not need twenty different choices. We need one free, open, and solid solution that everybody uses.
What the main leaders of the industry should really is to found a groupo that defines that standard. This would be their chance to really make the world a (slightly) better place.
It wasn't until 2011 that Subversion dropped below 50% market share in the Eclipse Community Survey. Something new and shiny will come along and replace git.
My first job used SVN and it limited workflows compared to git. Branches are more expensive, so people adapt their workflows. I used git-svn on that job, which allowed me to refactor locally; not a feature available to me or others once pushed.
My colleagues evaluated git and thought it was too complicated. A few years and a lot of employments later, they’re all using git. I don’t know if it was peer pressure from enough young recruits, but the verdict is clear: git is better than SVN.
Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps.
A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
You can absolutely spin up vanilla git on your own machine, but try using it for a week. From some quick Googles it looks like Github has 80% market share of version control with Dollar Store Github (Gitlab) picking up the rest. Everyone uses the pretty tool stack built on top of it because it is overly complex. Git didn't add anything profound that couldn't have been added as a feature to another VCS.
And nowadays it offers so much more like the GHAS, codespaces, copilot, actions and workflows etc that companies who get entrenched would need half a dozen different vendors to cover the feature set if they were to migrate from GitHub.
And in general I feel that their gh cli tool doesn’t get enough praise. Being able to do easy API calls and queries for use in shell scripts (or just the terminal) is great, and the gh copilot is occasionally useful as a refresher for command syntax, or for deciphering some oddball git command you found online.
It’s a massive beast to tackle, and few people have a reason to. I don’t see anything doing what git does having a chance at competing with it. It requires a paradigm shift and a completely new product/approach to versioning to break the git dominance.
I recently started a new job that uses SVN, one thing that really catches me out is that it doesn't automatically add new files. Is there some easy trick I am missing to tell SVN to automatically track everything recursively under a folder?
Torvalds liked to code on planes back when you couldn't use the internet and that's just about the only use-case I've ever heard where I agree distributed makes sense.
Kids these days can't even code at all without chat-GPT, there's a central server hosting the git repo anyway, the whole architecture feels like it was designed for dial-up.
I can't think of anything that was doable 30 years ago compute and bandwidth-wise, that we can't do today due to performance reasons, except client-server source control...
My very first programming job used Subversion. Even as a freshly minted programmer I knew we were using it completely wrong.
My first assignment was to spend several days picking apart an extremely nasty merge conflict from two branches nearly six months diverged. That was a very stupid thing to trust me with, as a major refactor was being blessed by my idiot hands.
Management could not figure out how they wanted to maintain a master/production branch.
Our 'trunk' was the develop branch, and any time we wanted to push to production.... We deleted the master branch and made a copy of develop. Master branch had no history, you had to track it back into develop and hope you found a trailhead from there.
It was a very bad time, and we were left with a very bad product. By the time I left, the codebase was so rotten and broken that we'd abandoned all hope of fixing the deeper issues.
I really hated subversion, but mostly the company was just unbelievably mismanaged. I'm sure you can use SVN in a sane way, just not like this
Besides the frontend problems with git that everybody talks about, the backend could be improved. It's now line-oriented. It would be more useful if it knew about the semantics of the language you were writing so it could show you semantic differences. That might also provide a mode for binary files which git doesn't handle very well now.
Actually, it’s not the backend which is line oriented, it’s the front end. The backend doesn’t dissect files, it stores the entire new file when even one line is changed and relies on object compression to find the similarity in the rest.
Before we can get a vcs that understand semantic diffs, we need a way to communicate semantic diffs. That way each file type can have its own “semantic differ”. Similar to how language servers help abstract away the differences for IDEs
The diffs don't have to be line-oriented if you are using a diffing tool that isn't based on line changes.
Git itself just stores snapshots of your files, then you can bring your own diffing tool that works in any way you'd like, it's not limited to line based diffing.
You can set a lot of that up with the shared config in the .vscode folder, and then enforce it with whatever rule set you chose and however you chose. We do it with auto-save and the prettier engine for Typescript, the C# engine for C#, the standard VSC engine for C++, whatever the Rust plug in for Rust is called for Rust and so on. Technically it’s a little more free to be done differently by different developers because it’s rather easy to not use our “standards” if you so chose, but if you don’t follow our defined syntax for languages it’ll likely not pass through our CI/CD pipeline, or in a few cases (like indents, line-ends) simply get altered to the standard.
I do agree with your point about different IDEs, but I think VSC is actually one of the better tools for helping development teams unify the way they code. Then again, all our developers use VSC, except for that one guy who is stuck in regular VS and often has a ton of swearing because of it. Which is pretty much the legacy experience of regular VS from having used it for 10 years myself. It still amazes me just how slow it becomes with certain plugins, and how bloaty the various templates are. But hey, he’s happy/angry with it sooo.
I guess the story becomes a little different if you work with PHP or Java or similar, where VSC is arguably much worse than its competition, but you’ll likely still have some developers who prefer it because they also work with other languages. Or in Python heavy environments where there are also a lot of great IDEs for the more ML/AI/BI side of things.
You could probably do better, yes. But if someone is to do better, I'd hope they actually learn git first.
A lot of alternative tools come up because of people writing them being unwilling to learn git. There are a handful of concepts and a few handfuls of commands and thats it.
And once someone learns git throroughly, they usually come to see that it is actually good enough, and dont bother making something new.
"Fine" is not "optimal". The mere fact that something does the job does not make it the best possible thing that does the job.
The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot commit a partial resolution of a conflict: you simply have to bail out and try and put your histories in a state that is more acceptable to the merge algorithms before trying again.
Maybe you want more local clones (git clone -l -s) or to use worktrees, so you can leave a merge conflict pending in one of them?
Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.
> Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved.
Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.
I do, thank you! (But it will never be the case that conflicts are modelled in Git, unless one uses notes or something to build a more expressive database on top of it, whereupon I think it's not really reasonable to call the resulting system "Git".)
The git object system is based on objects having types. There was a time when the "tag" object type did not exist. The only difference between then and now is the installed base.
As far as I can tell, Pijul[0] aims to have better conflict resolution and merge correctness.
I'm not super into the theory, so I can't explain it very well, but it looks promising.
An obvious area for improvement would be semantic version control.
If the VCS would have an understanding of not only what has changed but also how this affects the code, it could deduce a lot if interesting facts about commit blocks.
Like ignoring simple refactorings (e.g. renamings), reducing merge conflicts, etc.
* Large files (LFS is a not-very-good poorly integrated hack)
* Very large projects (big company codebases). Poor support for sparse/partial checkouts, stateful operations (e.g. git status still scans the whole repo every time on Linux), poor & buggy support for submodules.
* Conflict resolution. It's about as basic as it can be. E.g. even zdiff3 doesn't give you quite enough information to resolve some conflicts (you want the diff for the change that introduced the conflict). The diff algorithms are all fast but dumb. Patch based VCS systems (Darcs, Pijul) are apparently better here.
IMO the most interesting projects that are trying to solve any of these (but not all of them sadly) are Jujitsu and Pijul.
> The diff algorithms are all fast but dumb. Patch based VCS systems (Darcs, Pijul) are apparently better here.
Isnt one of git's core features that it can work as a patch based system?
It's my understanding (and please correct me if I'm wrong) that Linux patches can come in via mailing list, as a diff. That would make the person committing different from the owner of the change (also reflected in git's design)? Do Darcs and Pijul just have a string of patches on top of the original source file?
Got can apply patches, yes. But I mean when it has two commits (which are snapshots, not patches) and it uses a diff algorithm to synthesise a patch between them.
It uses an algorithm which is great from a computer science point of view (low algorithmic complexity, minimal length, etc.) but pretty bad from a semantic point of view (splitting up blocks, etc.).
There are a couple of attempts to improve this (DiffSitter, Difftastic) but they don't integrate with GUIs yet.
It would be hard to get past the network effects. Just like how we are stuck with SMTP, JavaScript, PDF, HTML, etc.
The only way I could see it changing is if we have a complete paradigm shift. This is what happened when we went from SVN to Git (centralised to distributed).
In my opinion the feature Git has always been missing is version control of branches. Of course the immediate consequence would be that you'd be able to roll back changes to branches but there'd be some more fundamental consequences as well. I'm pretty sure some of the problems with GUI's/wrappers around Git break down because there's no tracking of branches/tags.
Besides that it's pretty much endgame in my opinion if you consider only the functionality it's meant to solve. If another "better" VCS would ever become popular I feel it would have to be a drastic change to the way of working with VCS, even more drastic than SVN to Git was. There's some cruft in Git that could probably be taken away, and that would make Git better in a theoretical sense, but in the real world that would never happen (unless we get sideswiped by another industry or platform).
Can you clarify what you mean by "version control of branches"? Branches in Git are just labels of objects. Are you talking about having a history of which objects a branch has previously labelled, like the reflog?
Yeah, I feel the reflog is more of a tool to do introspection on a git repository than that is a tool for collaboration. It's just something I've felt was missing from Git. If you're looking at the main branch of a repository, what was the previous version of that branch?
The way we work around that missing feature is by tagging commits so we don't forget what revision a release was made at for example. A sequence of release tags basically is a meta branch, a history of the release branch, but managed manually instead of through git.
Phabricator and Gerrit both do a really good job of this. To me Git works fine as a pure "version control" system, but the process of collaborating on a branch before it gets merged into a shared branch seems to be beyond the scope of version control -- something that a higher layer tool is ideal for.
Git is great for keeping track of logical history, but personally I find that it is missing tools for handling physical history. Reflog is a step in the right direction but it has a limited size and AFAIK it is not possible to share a reflog between clones. Which leaves "cp -r repo repo.backup" as the best option.
Of course, as long as you only do additive changes via commit/merge/revert, the logical history is equivalent to the physical history, but commands like rebase break this model. And despite the flaws of rebase workflows, sometimes it is the best option, like when maintaining a fork.
To my surprise Vim actually has something like this - logical history with undo/redo and physical history with g+/g-/:earlier/:later
Another thing I would like is some way to "fold" multiple small commits into one bigger one (for display purposes only) as it would let me split large diffs into minimal, self-contained commits while maintaining a reasonable git history.
The simple explanation:
Logical history - what you see when you do "git log --all".
Physical history - doing "git log --all" every time a repository updates and then storing each output as an entry into another history log. Kind of a "history of histories"
The complex explanation: a git repository at a particular time consists (mostly) of a graph of commits. This graph represents the logical history of code changes in the repository. The graph can be updated in an append-only fashion (using commit/merge/revert) or in a destructive way like with rebase and reset. The physical history is simply the history of the graph over time.
I think Git itself is probably too entrenched to be displaced by now, but I recently came across Graphite (https://graphite.dev/) and, while it’s all still Git under the hood, it abstracts away many of the common pain points (stacking PRs, rebasing) and has nice integrations with GitHub and VS Code.
Something that is better should be able to track moves, not just store state. Moves of files and even partial content moved within (text) files. Unfortunately, that needs a tight coupling to the editor, so I doubt that's going to happen.
308 comments
[ 62.2 ms ] story [ 2720 ms ] threadThere is definately scope for a beginner friendly UI/UX. Julia Evans has a post lately about confusing aspect of git. Ability to version control large files (like git-lfs) would be a nice addition.
If it doesn't have multiple clouds providers with pull requests, and at least one of those clouds providers isn't a megacorp, it probably won't be the safe boring choice, unless it's fully P2P.
It needs to be packaged in distros, have GUI integrations, etc.
Fossil looks really cool, I really like how they integrate the wikis and issues. But I don't know anyone who uses it, and the cloud providers seem to be smaller "Could go away any time" companies.
I've never really explored any other VCSes, because none ever seem like they're going to be serious competitors.
I'd be more interested in enhancing Git, but it seems a lot of the most interesting git plugins and extensions aren't updated, like GitTorrent.
¿Que?
If you're wondering whether we can make something better than GitHub, there's dozens of git hosting alternatives that you might like better such as Forgejo and GitLab.
If you're saying "but I already know git", then there's still dozens of alternative hosting sites or methods!
There are others that are almost as good, I suppose what I should have said is "Can we make something better than GitHub for the hypothetical better non-git VCS", since without that it's hard to imagine using anything but Git.
We should all stay on Facebook also if they're the best because everyone's on Facebook and the network effect has benefits; somehow it seems people have more sense than that and we can actually switch to smaller services which are more aligned with what we want
I could imagine people switching if someone made another site with some kind of killer app and promoted it with a million dollars of ads, but... At the moment, the only feature the alternatives focus on is usually privacy, which is clearly not enough to make average people switch.
Network effects aren't the only factor that matters, just a really big one for most.
There are some GithHub-alikes, the most obvious is GitLab which you can also host yourself but all (or at least some of) the extras you get for free with GitHub are behind payment walls.
My current favourite is Codeberg, it uses Forgejo underneath (which is a fork of Gitea itself a fork of Gogs - all of which you can self host). Codeberg is run by a non-profit and are very much aligned with my ideals. They are also slowly adding nice features like their Woodpecker CI.
One that is growing in popularity and is a little less "GitHub-y" is SourceHut (which also has Mercurial support).
The main issue is that GitHub has really cornered the market. They give so much out for free that is difficult for others to compete with and it has become the de-facto place to host your project. This can mean that hosting anywhere other than GitHub will limit discoverability and contributions from people if they don't want to make an account or work out how to deal with whatever forge you are using.
However one thing that is coming that may help alleviate some of that is forge federation which will allow you to interact with various forges from your "home" forge - which hopefully prevents the need to make an account to make PRs or raise issues.
Edit: I see your other comment now, what could a better GitHub be that supports a better-than-git VCS. Well there did used to be places to host Darcs projects like the Darcs Hub but I don't know if some of the newers ones like Pijul or Jujutsu have any forge support yet.
Edit2: Oh it seems Pijul has "The Nest" for hosting.
There's no native forge yet.
For example, our "Piper" backend at Google is a native backend in the sense that it stores all data in its own database. I think the most exciting thing about that backend is that it's cloud-based so users will be able to access each others' commits (e.g. `jj show <commit id from chat>`) without requiring a push.
it's just backup of current state with irrelevant commit message. Everything is described at the end of the work in PR's description and squash merged.
Unfortunately a good chunk of the industry doesn't have the discipline to do this.
If you have ever worked in a project where there was discipline around committing, you know there is lots of value in doing so (rebasing becomes easier, you unlock the power of bisect, log is actually useful).
Also doing PR code review is soo much nicer if each commit is logically self contained with a nice commit message.
I think they just want to replace some of the words with alternatives that they prefer. Because at some point someone is going to winge that update should be syncronise and not pull, and save should be push and therefore git is the worst.
Git is distributed, and that means you can't get away from push, pull and fetch, however you name them.
If want you want is a way to avoid making "New New Presentation FINAL 2", then pretty much all features of most source control systems are superfluous.
To me that doesn't mean Git needs fixing, it means it's definitely not the right tool for your job.
Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control.
Learning how to use your tools is part of ANY trade.
If you were talking about things like Kubernetes, LLVM, Ghidra then I'd agree.
But no git. This is not some expert tool.
This tool's purpose is literally to manage your characters' history, that's it.
Git could be used by any other profession that deals with letters - article writers, book writers, etc, etc.
Yes, but you seem to heavily underestimate the complexity of the problem and the volume of the use cases that git solves.
The fact that git is used by experts and professionals is not an excuse for poor UX. The experts and professionals are almost never Git experts or professionals. I use my car every day, that doesn’t make me a mechanic. Having to understand the inner workings of a tool is an indication of poor design, not a gatekeep we should seek to maintain.
One is: how do you effectively manage changes to a codebase over time? Git has a model that, for day-to-day use, has primitives like "commit", "branch", and "tag". You also have to understand the difference between your working copy, what is staged for commit, and any other commit in history. These, in combination with the operations you can do with them is actually somewhat complex. This is the thing I am saying people need to learn. And people quite often complain about it.
The other is the organization of git's porcelain layer, the arguments and flags each subcommand takes, and how stuff is presented back to the user. I think git stands to make significant improvement here. Be that as it may, the tool exists as it is. So your options are to use a different VCS entirely, use a different frontend, or learn how to use git as-is.
If you choose to use git but deliberately avoid learning e.g. what a rebase is and why it's useful, you are choosing to be an ineffective developer. Could it be better in some ways? Yes, but it isn't.
I don't think the car analogy is particularly compelling. The "primitives" of a car are already much simpler than git's. The fundamental primitives of a car are "go faster" and "go slower", along with some supporting things like managing your headlights, windshield defrosting, wipers, and horn.
While additional tools are being added to cars to make them safer (e.g. a backup cam or collision detection), the complexity of those tools is increasing rapidly which makes them more prone to failure. And a driver is absolutely not excused from causing an accident just because one of these safety tools failed. You still have to know how to safely operate your vehicle in a variety of conditions.
Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from having a simple and reliable tool fit for purpose of cable clamping.
There is certainly a need for competent and "proper" software engineering that require special tools and detailed training, but I would argue it's niche and filled by people who build the tools themselves.
IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.
They're doing brick-laying work until they aren't. Most problems are easy to solve and don't require very much fussing over. The expertise comes in knowing which problems are worth fussing over and which aren't.
Technology is becoming ever more present in our lives, not less.
Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.
I fully agree with this observation, but the reality is that this is where things are going.
Software quality is simply not that relevant today for the majority of software. As long as the billing works fine, the management is happy to see your website barely working - screw the quality if the money is coming in anyway.
Such software costs much less and can be built by bricklayers.
You can have both - powerful and user friendly.
This idea that engineer's tools must be a mess that is fine as long as enables to do something is idiotic.
The same argument was repeated whenever C or C++ vs Rust discussions were happening
"Just learn C and memory management (and all the quirks)"
"Just use this new language constructs and you're fine..."
and in reality we ended with a lot of CVEs - 70% in both Chrome and Windows were related to mem. issues.
There's absolutely no reason why git's CLI cannot be better than it currently is. Once again - there is no reason.
Proof? There are CLI wrappers or even GUIs like GitHub Desktop that make whole experience way better.
Unless of course you spend time to learn git, but its complexity is closing up to C++. And using a VCS shouldn't require that amount of effort. It should just get out the way (I must admit, git usually gets out of the way, as long as you use only the base commands... but when it gets in the way, that's when the fun starts)
[0] https://github.com/martinvonz/jj
[1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796
[2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662
Even though Python is the language I’ve used most, I wouldn’t want to use it for something with a lot of uncertainty and that will suffer many changes. Type systems make it so much easier to change things early on without breaking everything. I’d probably pick F# or similar.
Most of the developers (some of them being former Mercurial and Git developers) including me generally seem to like it. Based on my own experience, I think it's a pretty excellent choice, but I'd be a bit biased as a die-hard Haskell/C programmer for something fast with types.
Perhaps the author can explain - when you clone the repo with
jj git clone
It pulls down a branch that is auto generated like pull-(hash)
I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what.
Another way to say it is that everything works great until I have to pull down the repo from another machine - then the branch history is not what I expect. And I just couldn’t make sense of it or get it to square with what I expected.
I actually created a custom GPT and fed it the jj code and documentation to try and get it to explain it to me to no avail. Jj is so good, I’m willing to give up IDE integration with git if I could just crack this nut.
https://github.com/martinvonz/jj/discussions/2691
There's differences, such as that pgp is more complicated under the hood and it being a cryptographic system that needs to be foolproof whereas in git you can nuke and re-clone without data loss most of the time, let alone confidentiality/integrity loss. It just feels very similar in that only expert users properly use it and most people who could make use of it don't bother learning because the interfaces available are such a struggle (beyond basic operations anyway)
Whether it can all be solved with a simpler user interface, or whether it would require a simpler underlying system to be able to make simpler standard operations, is where I'm not sure
While git is good under the hood, then it has not really user-friendly interface.
Also git heavily benefits from GitHub's success, which locks us with git :(
I wrote about it here https://trolololo.xyz/github - GitHub is really good, but there's a small problem with that
One of the most amazing things about Fossil is how you can track the history of a file not just backwards, but also forwards, something which is pretty whacky with git.
https://www.fossil-scm.org
_Nothing_ history-relevant can be changed via manipulation of the Fossil db. In terms of db records, as opposed to space, the db is about 80-90% a transient cache of data which is generated from the remaining (100% immutable) data. Any changes you make to that transient data will be lost the next time that cache is discarded and rebuilt. A longer explanation can be found at:
https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
As for DVCS, the best one I've used is Darcs: https://darcs.net/ There are some sticky wickets (specifically, exponential-time conflict resolution) that hindered its adoption.
Thankfully, there's Pijul, which is like Darcs but a) solves that problem; and b) is written in Rust! The perfect DVCS, probably! https://pijul.org/
For a new versioning system we do not need twenty different choices. We need one free, open, and solid solution that everybody uses.
What the main leaders of the industry should really is to found a groupo that defines that standard. This would be their chance to really make the world a (slightly) better place.
It wasn't until 2011 that Subversion dropped below 50% market share in the Eclipse Community Survey. Something new and shiny will come along and replace git.
Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
"Github isn't all git [some features of GitHub are not in Git], but all git is Github [but all features of Git are in GitHub]."
Maybe my interpretation is incorrect?
My colleagues evaluated git and thought it was too complicated. A few years and a lot of employments later, they’re all using git. I don’t know if it was peer pressure from enough young recruits, but the verdict is clear: git is better than SVN.
A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
And in general I feel that their gh cli tool doesn’t get enough praise. Being able to do easy API calls and queries for use in shell scripts (or just the terminal) is great, and the gh copilot is occasionally useful as a refresher for command syntax, or for deciphering some oddball git command you found online.
It’s a massive beast to tackle, and few people have a reason to. I don’t see anything doing what git does having a chance at competing with it. It requires a paradigm shift and a completely new product/approach to versioning to break the git dominance.
You can't set up a GitHub server.
https://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserv...
Although...you can set up a Github on-prem server -- or at least this used to be true. Talk to Github Sales and be prepared to write a check.
Oh here we go again. You are wrong my friend. Firing up a basic SVN server is a matter of minutes. You just need to run several simple commands.
Kids these days can't even code at all without chat-GPT, there's a central server hosting the git repo anyway, the whole architecture feels like it was designed for dial-up.
I can't think of anything that was doable 30 years ago compute and bandwidth-wise, that we can't do today due to performance reasons, except client-server source control...
My first assignment was to spend several days picking apart an extremely nasty merge conflict from two branches nearly six months diverged. That was a very stupid thing to trust me with, as a major refactor was being blessed by my idiot hands.
Management could not figure out how they wanted to maintain a master/production branch.
Our 'trunk' was the develop branch, and any time we wanted to push to production.... We deleted the master branch and made a copy of develop. Master branch had no history, you had to track it back into develop and hope you found a trailhead from there.
It was a very bad time, and we were left with a very bad product. By the time I left, the codebase was so rotten and broken that we'd abandoned all hope of fixing the deeper issues.
I really hated subversion, but mostly the company was just unbelievably mismanaged. I'm sure you can use SVN in a sane way, just not like this
Git itself just stores snapshots of your files, then you can bring your own diffing tool that works in any way you'd like, it's not limited to line based diffing.
I do agree with your point about different IDEs, but I think VSC is actually one of the better tools for helping development teams unify the way they code. Then again, all our developers use VSC, except for that one guy who is stuck in regular VS and often has a ton of swearing because of it. Which is pretty much the legacy experience of regular VS from having used it for 10 years myself. It still amazes me just how slow it becomes with certain plugins, and how bloaty the various templates are. But hey, he’s happy/angry with it sooo.
I guess the story becomes a little different if you work with PHP or Java or similar, where VSC is arguably much worse than its competition, but you’ll likely still have some developers who prefer it because they also work with other languages. Or in Python heavy environments where there are also a lot of great IDEs for the more ML/AI/BI side of things.
A lot of alternative tools come up because of people writing them being unwilling to learn git. There are a handful of concepts and a few handfuls of commands and thats it.
And once someone learns git throroughly, they usually come to see that it is actually good enough, and dont bother making something new.
They don't even bother to add directory tracking ;)
The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot commit a partial resolution of a conflict: you simply have to bail out and try and put your histories in a state that is more acceptable to the merge algorithms before trying again.
Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.
Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.
[0] https://pijul.org/
If the VCS would have an understanding of not only what has changed but also how this affects the code, it could deduce a lot if interesting facts about commit blocks.
Like ignoring simple refactorings (e.g. renamings), reducing merge conflicts, etc.
* UX, obviously.
* Large files (LFS is a not-very-good poorly integrated hack)
* Very large projects (big company codebases). Poor support for sparse/partial checkouts, stateful operations (e.g. git status still scans the whole repo every time on Linux), poor & buggy support for submodules.
* Conflict resolution. It's about as basic as it can be. E.g. even zdiff3 doesn't give you quite enough information to resolve some conflicts (you want the diff for the change that introduced the conflict). The diff algorithms are all fast but dumb. Patch based VCS systems (Darcs, Pijul) are apparently better here.
IMO the most interesting projects that are trying to solve any of these (but not all of them sadly) are Jujitsu and Pijul.
Isnt one of git's core features that it can work as a patch based system?
It's my understanding (and please correct me if I'm wrong) that Linux patches can come in via mailing list, as a diff. That would make the person committing different from the owner of the change (also reflected in git's design)? Do Darcs and Pijul just have a string of patches on top of the original source file?
It uses an algorithm which is great from a computer science point of view (low algorithmic complexity, minimal length, etc.) but pretty bad from a semantic point of view (splitting up blocks, etc.).
There are a couple of attempts to improve this (DiffSitter, Difftastic) but they don't integrate with GUIs yet.
The only way I could see it changing is if we have a complete paradigm shift. This is what happened when we went from SVN to Git (centralised to distributed).
Besides that it's pretty much endgame in my opinion if you consider only the functionality it's meant to solve. If another "better" VCS would ever become popular I feel it would have to be a drastic change to the way of working with VCS, even more drastic than SVN to Git was. There's some cruft in Git that could probably be taken away, and that would make Git better in a theoretical sense, but in the real world that would never happen (unless we get sideswiped by another industry or platform).
The way we work around that missing feature is by tagging commits so we don't forget what revision a release was made at for example. A sequence of release tags basically is a meta branch, a history of the release branch, but managed manually instead of through git.
Of course, as long as you only do additive changes via commit/merge/revert, the logical history is equivalent to the physical history, but commands like rebase break this model. And despite the flaws of rebase workflows, sometimes it is the best option, like when maintaining a fork.
To my surprise Vim actually has something like this - logical history with undo/redo and physical history with g+/g-/:earlier/:later
Another thing I would like is some way to "fold" multiple small commits into one bigger one (for display purposes only) as it would let me split large diffs into minimal, self-contained commits while maintaining a reasonable git history.
thanks in advance
The complex explanation: a git repository at a particular time consists (mostly) of a graph of commits. This graph represents the logical history of code changes in the repository. The graph can be updated in an append-only fashion (using commit/merge/revert) or in a destructive way like with rebase and reset. The physical history is simply the history of the graph over time.
and the logical history is the filesets which are the nodes in the graph which is the branching sequence of commits
the issue is that the 'logical history' is the reason git was built
and the 'physical history', seems to me, is only feasible because we have the regular git sequence of commits
I think there's no magic and we'll still have to resolve merge conflicts on our own, but my sense is it does simplify repetitive operations.
Hope this helps!