Ask HN: Can we do better than Git for version control?

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen.<p>I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare to use on a team for any serious work.<p>Git has no such problem. There’s nothing it can’t do. Instead, the only limitation is on the user being able to know how to get Git to do what they want it to do. Thankfully, that’s always solvable with a quick read of the documentation or web search.<p>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. If you abstract away the power, you are no longer solving all the problems that Git solved. People just don’t realize what problems are being solved because they never lived through those problems with the previous VCSes.<p>You know what’s easier than building a new VCS better than Git? You know what’s easier than using a different VCS from the rest of the world? You know what’s easier than designing a miraculous abstraction on top of Git?<p>Learning Git.<p>Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert. It will be a lot less effort with a lot more benefit. Trust me on this. It will be well worth it for your career and for your personal computing life as well.

Along what axis do you want the VCS to be &quot;better&quot; than git?<p>For example, git&#x27;s cli user interface is monstrous (yes, I know, you personally have 800 cli commands memorized and get them all right every time, that doesn&#x27;t make it &quot;good&quot;). From the outset, the maintainers of git basically decided &quot;it&#x27;s too much work to make all the cli flags behave and interact consistently&quot; so they didn&#x27;t. This allowed git to grow fast, at the cost of the cli user experience.<p>That said, git is big enough that multiple companies have come along and &quot;solved&quot; the git UI problem. None of these aftermarket UI layers are perfect, but there are enough of them and they are different enough that you can probably find one that is good enough for you, along whatever axis you personally dislike the git UI (examples include [0], [1], [2], which tackle very different user workflow problems).<p>[0] <a href="https:&#x2F;&#x2F;git-fork.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;git-fork.com&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;graphite.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;graphite.dev&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7565885">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7565885</a>

Jujutsu version control system looks very promising in the way it brings the best of other DVCS&#x27;es together and innovates on various concepts. It has been discussed a number of times on HN before.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a><p>[1] 4 montsh ago, 261 comments <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36952796">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36952796</a><p>[2] 2 years ago, 228 comments <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30398662">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30398662</a>

Yes. From the creators of Sqlite, you got Fossil.<p>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.<p><a href="https:&#x2F;&#x2F;www.fossil-scm.org" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.fossil-scm.org</a>

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).<p>Unless of course you spend time to learn git, but its complexity is closing up to C++. And using a VCS shouldn&#x27;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&#x27;s when the fun starts)

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.

I think we already have that, Fossil. Unfortunately network effects are a bitch to overcome. But with Fossil you get an elegantly architectured system that includes a ton of forge tools the absence of which have led to centralization of git repositories in places like github. It&#x27;s simpler, saner, smaller and more capable.

Don&#x27;t know about a better solution, but there might be a better interface. My pet theory is that focusing more on the fact that a repo is a directed graph would help. Make the language more graph-like (less &quot;commit&quot; more &quot;node&quot;, less &quot;branch&quot; more &quot;path&quot;, less &quot;repo&quot; more &quot;graph&quot;). This kind of thinking would, I think, expose a bunch more primitives that should be surfaced more explicitly than they are (lots of things are &quot;possible but not easy&quot; in git), and make it easier to learn for anyone with a math background. And make web searches easier too.<p>(Pretty sure I&#x27;ve said this before and it&#x27;s been shot down before, so...)

Yes. Here are areas where git sucks:<p>* UX, obviously.<p>* Large files (LFS is a not-very-good poorly integrated hack)<p>* Very large projects (big company codebases). Poor support for sparse&#x2F;partial checkouts, stateful operations (e.g. git status still scans the whole repo every time on Linux), poor &amp; buggy support for submodules.<p>* Conflict resolution. It&#x27;s about as basic as it can be. E.g. even zdiff3 doesn&#x27;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.<p>IMO the most interesting projects that are trying to solve any of these (but not all of them sadly) are Jujitsu and Pijul.

As far as I can tell, Pijul[0] aims to have better conflict resolution and merge correctness. I&#x27;m not super into the theory, so I can&#x27;t explain it very well, but it looks promising.<p>[0] <a href="https:&#x2F;&#x2F;pijul.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;pijul.org&#x2F;</a>

The only thing I wish git handled better out of the box, with without any flags&#x2F;setup, is large&#x2F;binary assets.<p>LFS is ok but it still feels like a kludge to me.<p>The cli does not bother me, there are many tools that offer alternatives&#x2F;overlays&#x2F;UIs. Not saying it is perfect or even good, but it&#x27;s good enough - for me at least.

Fossil by sqlite think so as does Sapling by Facebook <a href="https:&#x2F;&#x2F;sapling-scm.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;sapling-scm.com</a>

Subversion was really good. It wasn&#x27;t perfect, but it was relatively painless.<p>Instead everyone switched to a &quot;distributed&quot; version control system that is such a pain in the ass it is all now hosted by a single company.

Besides the frontend problems with git that everybody talks about, the backend could be improved. It&#x27;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&#x27;t handle very well now.

What do you recommend for non-programmers, who would still benefit from version control system.<p>Examples: - Book author using markdown &#x2F; static site generator to publish a book. Uses visual editors like Typora. - Product designers for open-source hardware. Various design files, SVG etc.<p>I’ve experimented with a “GUI only” git flow - just to see what is possible, so I could introduce the concept to others.<p>I found GitHub desktop app (<a href="https:&#x2F;&#x2F;desktop.github.com&#x2F;)did" rel="nofollow noreferrer">https:&#x2F;&#x2F;desktop.github.com&#x2F;)did</a> a great job of visually showing git flows and functions, but for a non-tech&#x2F;programmming person, the tool would be daunting.<p>Curiosity what your suggested tech stack would be - sans Terminal…

Git views the codebase as mutable. It&#x27;s really well set up for changing the historical record to reflect how you wish it had been done. This is necessary for large team dev efforts - it means the history is mostly a sequence of atomic changes to functionality or code structure, with some reverts when CI judged the patch inadequate.<p>Fossil views the historical record as immutable. Your sequences of mistakes, iteration, failed experiments are all diligently recorded. I like that, means I get to revisit missteps and abandoned branches later. However it is clearly a scaling hazard. I don&#x27;t want to see the incremental hacking around of a thousand other people. Nor would I want to prohibit that sort of exploration.<p>My personal work is in fossil repos, going back a decade across various operating systems and versions of fossil. It has literally never let me down.

An obvious area for improvement would be semantic version control.<p>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.<p>Like ignoring simple refactorings (e.g. renamings), reducing merge conflicts, etc.

Yes, it will be superseded. Will the new thing be “better?” I guess that depends on the metric and needs. “ls” was done but exa&#x2F;eza came along and they have users.<p>Pondering it, most of the easy things I can think about are really workflow issues on top of git. Git doesn’t exactly enforce them all though so maybe tighter integration would be a reason to change from git if it could not be adapted. Short of that, it’s hard to imagine that a new generation of engineers simply won’t do a new thing to do a new thing; there will be a “git considered harmful” article or a “modern” replacement for git.

I personally think that Fossil is a good example that&#x27;s extant and used in serious projects. There&#x27;s that one called pijul which also looks good in theory, but I haven&#x27;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.

Perforce.<p>As for DVCS, the best one I&#x27;ve used is Darcs: <a href="https:&#x2F;&#x2F;darcs.net&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;darcs.net&#x2F;</a> There are some sticky wickets (specifically, exponential-time conflict resolution) that hindered its adoption.<p>Thankfully, there&#x27;s Pijul, which is like Darcs but a) solves that problem; and b) is written in Rust! The perfect DVCS, probably! <a href="https:&#x2F;&#x2F;pijul.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;pijul.org&#x2F;</a>

Of course there is a room for improvement... One of the biggest issues is usability&#x2F;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&#x2F;SVN Commit - nothing more to learn in Subversion...

In my opinion the feature Git has always been missing is version control of branches. Of course the immediate consequence would be that you&#x27;d be able to roll back changes to branches but there&#x27;d be some more fundamental consequences as well. I&#x27;m pretty sure some of the problems with GUI&#x27;s&#x2F;wrappers around Git break down because there&#x27;s no tracking of branches&#x2F;tags.<p>Besides that it&#x27;s pretty much endgame in my opinion if you consider only the functionality it&#x27;s meant to solve. If another &quot;better&quot; 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&#x27;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).

Yes we can. The shortcomings of git are that it doesn&#x27;t handle binary files well, and you can&#x27;t clone a slice of a repo. the system after git will handle both of those. mono repo or not is not a question with aftergit because you can clone just a subdir and work there, without the overhead of cloning the whole thing, but also without the weight of keeping up with commits happening outside of your directory.

There are already various ways in which mercurial or perforce are better than git, and big companies like Google and Meta have hacked on the systems they started with so much that one can hardly say they’re still perforce&#x2F;hg. There can be disadvantages there but it seems obvious to me that better systems are possible. It feels to me like the real question is whether GitHub is the endgame.

I do believe that it is possible, at least at the API (cli) level.<p>While git is good under the hood, then it has not really user-friendly interface.<p>Also git heavily benefits from GitHub&#x27;s success, which locks us with git :(<p>I wrote about it here <a href="https:&#x2F;&#x2F;trolololo.xyz&#x2F;github" rel="nofollow noreferrer">https:&#x2F;&#x2F;trolololo.xyz&#x2F;github</a> - GitHub is really good, but there&#x27;s a small problem with that

You could probably do better, yes. But if someone is to do better, I&#x27;d hope they actually learn git first.<p>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.<p>And once someone learns git throroughly, they usually come to see that it is actually good enough, and dont bother making something new.

My experience is that the power of any technology unfolds gradually - with git it&#x27;s like okay let&#x27;s master the commands for a single repository on a single server for a single user up to a certain level of adequacy. Then (depending on need), let&#x27;s add multiple repositories on the same single server for the same single user. Then add multiple servers (including a git remote server). Then add multiple users ... etc ... of course the magic of git is you can unfold those needs in any sequence. Often when I find I do not understand something (that I thought I understood), I go back in scope to an earlier unfolding, eliminating other factors.<p>I&#x27;m sure git can be improved, but I think the biggest improvement comes from the user being improved with their understanding of the scope of capabilities. I have yet to see a good tutorial on this (among the plethora of git tutorials out there). This reminds me of the (excellent) video where the &quot;Harvard Professor Explains Algorithms in 5 Levels of Difficulty&quot; [1]<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=fkIvmfqX-t0" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=fkIvmfqX-t0</a><p>I would love to see a Channel where that is the entire theme - explaining everything in 5 levels of difficulty.<p>All this being said, at each of the &quot;5 levels of difficulty&quot; of git, are there improvements to be made. I&#x27;m sure there are. It would be good to focus the answer on each of those levels.

Git is the product of an engineer, not a designer. Whereas engineers glue the parts together and make them work, the designer looks at the parts and questions if they are polished as to the intent and the logic.<p>I think git escaped to the public before having a designer&#x27;s refinement. Users need to learn about the glue and speak the glue language to git to make it work.

I think Git itself is probably too entrenched to be displaced by now, but I recently came across Graphite (<a href="https:&#x2F;&#x2F;graphite.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;graphite.dev&#x2F;</a>) 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.

Maybe there are certain domains where you could obviously do better. Take an artist wanting to version control images, i could imagine specialized tools that could be much better. For programming, there could be improvements for versioning groups of repositories that work together perhaps.<p>For standard needs, probably going to be difficult.

I more or less consider it a solved problem.<p>You&#x27;re mostly going to hear from people here who are annoyed with Git or otherwise more interested in the topic of version control than the median developer. For me, I think it provides a quite robust and well thought-out set of primitives, and then composes them upwards in ways which are about as good as one can expect.<p>Some stuff obviously isn&#x27;t well supported. Using the same Git repo to hold large binaries as well as source code is not well supported unless you reach for LFS - that&#x27;s the biggest downside I see.<p>Fossil would be my next bet. I&#x27;m waiting for someone to make an archaeology.co to rival GitHub.com for it.

git could be thousand of times more user-friendly, but its too command-line centric, so workflow is limited to complex &quot;sub tool invocations&quot;. GUIs for git exist but they add extreme overhead for simple workflows, perhaps some &quot;standard web interface&quot; backend should be prioritized( Github is popular due their UI). Another alternative is simplifying arcane command invocations, i&#x27;d expect &quot;git workflow_commandX file_target&quot; instead of tons of switches and parameters. There should be hundreds of such &quot;standard shortcut commands&quot; to reduce mistakes.

Yes. Take a look at Mercurial

Yes.<p>IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git.<p>I also think GitHub is in a unique space to really innovate on git and it’s a shame they’re not.<p>For example, I shouldn’t need to make a fork to make a PR. That’s absurd and the GitHub server should be able to apply ACLs based on the push identity.<p>There’s a couple more of these suggestions I can think of, but yeah, GitHub should do more in this space.

Disclamer: I&#x27;m working on it.<p>But yes, I think we can.<p>Almost everything can be better:<p>* Merges&#x2F;rebase&#x2F;branch management.<p>* Project management.<p>* Diff.<p>* Large files.<p>* User management.<p>* Partial checkouts.<p>* ACID semantics.<p>* Binary file management.<p>* User experience, including making it accessible to non-technical folks.<p>* A bunch of others.

Mercurial and Facebook&#x27;s sapling is much better than git in developer exp wise. Git is broken in many places but it become standard just because GitHub popularity and rise in development community that love to take whatever big orgs spoon feed them. Common developers these days don&#x27;t like to spend time researching things that won&#x27;t make quick bucks easily.

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 &quot;cp -r repo repo.backup&quot; as the best option.<p>Of course, as long as you only do additive changes via commit&#x2F;merge&#x2F;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.<p>To my surprise Vim actually has something like this - logical history with undo&#x2F;redo and physical history with g+&#x2F;g-&#x2F;:earlier&#x2F;:later<p>Another thing I would like is some way to &quot;fold&quot; 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.

Different perspective: We absolutely can do better than git… for non-text files that can’t be merged or stored as a sequence of diffs<p>I (briefly) looked into using git as an alternative to PDM for solidworks CAD files and it turns out git is absolutely not a good fit for this use case. Not surprisingly, I mean it wasn’t designed for that at all.<p>Point remains though that the world needs a better version control system, something like git, but that works with non text files, because boy do the actual solutions I’ve tried suck compared to the git experience<p>Software engineers are so lucky to have such a powerful tool for free, mechanical engineers or their companies pay tens of thousands of dollars for version control software that is far worse<p>PDM is a bit more than just version control but the version control is what my company wants and it’s so painful

Git is perfect, it just needs a good UI.<p>The best UI in my opinion is sourcetree, which is not available on linux.<p>I worked with sourcetree years ago (switched to linux last years and used smartgit client), I don&#x27;t know the current state, but old versions are available to download, and don&#x27;t require an atlassian account.<p>Some improvements I could suggest are the ability to ammend a commit which is not the last (and not pushed of course).<p>Currently if you want to ammend the third last commit for example, you have to soft reset last commit, push it to stash, reset the new last commit again and push it to stash, ammend the changes, then pop the previous 2 stashes and commit them one by one. This could be easily automated.

I am not sure if we will ever be able to replace git with anything else. It is so ubiquitous and just &quot;good enough&quot; 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.<p>For a new versioning system we do not need twenty different choices. We need one free, open, and solid solution that everybody uses.<p>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.

I remember a post on HN about how YAML was a terrible serialization format. A stricter subset of YAML (eg - StrictYaml) wouldve solved every single problem mentioned there.<p>Similarly, the solution to git is a subset of git (strict git).<p>Gits problem is that it is too powerful and assumes that it&#x27;s users are all git experts. You should be able to run git in &#x27;easy-mode&#x27;. Add, commit, checkout new branch, revert, squash merge. That&#x27;s all 90% of people need.<p>Then the intermediate folks can run it in mode 2, adding the ability to rebase, reset heads, cherry pick, revert, stash etc. This covers the next 9%.<p>The last 1% can use it in mode 3 for the rest.<p>Once you take away the fear of what you could break, git becomes far less intimidating.

I’ve used CVS, SVN, Arch, and Git. The main benefit of Git seems to be performance and atomicity. Arch was garbage. CVS works on files rather than directories. Git is a bit or a lot faster than SVN. That said, Git is much slower when there are large files in your repo.<p>Git is much harder to use than SVN. Particularly you see engineers struggling with resolving conflicts.<p>One benefit of Git was decentralization, but now Git is Github, it is centralized again.<p>Builds, IDE, programming languages should be 1st-class citizens. I don’t want to wrestle with .gitattributes or .gitignore.<p>What would I make better?<p>- Fast with large files. - Simpler. - Improved commit meta-data.

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&#x27;s going to happen.

We&#x27;ve been working on a data version control system called &quot;oxen&quot; optimized for large unstructured datasets that we are seeing more and more with the advent of many of the generative AI techniques.<p>Many of these datasets have many many images, videos, audio files, text as well as structured tabular datasets that git or git-lfs just falls flat on.<p>Would love anyone to kick the tires on it and let us know what you think:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Oxen-AI&#x2F;oxen-release">https:&#x2F;&#x2F;github.com&#x2F;Oxen-AI&#x2F;oxen-release</a><p>The commands are mirrored after git so it is easy to learn, but optimized under the hood for larger datasets.

I first user Git about 10 years ago, going from Accurev and Perforce. Those VCSs were a bit heavy to configure, but their UI allowed a lot of complex and easy workflows to happen at the same time.<p>Git won by being free and since a lot of people think using the terminal is somehow better, but we could have done a lot better in terms of UX and power. Command line programs force you to have a lot of context in your mind, and if git would have been designed with a UI it would have been probably better for everyone.<p>I still hope for better tools, but they&#x27;ll probably be based on Git, just with better default flows.

I&#x27;m not sure git is so bad that we need something different. It&#x27;s certainly awkward at times, but it is also mostly a side-tool: not the thing you think of when you think of being a developer, yet every dev uses it.<p>I suspect most people use just a tiny subset of git day-to-day, and google the rest when it comes up.<p>For this reason, I think if git is replaced, it won&#x27;t be because whatever comes along will be better objectively, it will be because a few reasons are touted that most people don&#x27;t understand but are willing to repeat, and some momentum builds behind the alternative.

Theo describes how Graphite was built on top of git (and Github) to improve DX: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;I88z3zX3lMY" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;I88z3zX3lMY</a><p>The main innovations seem to be:<p>- The concept of a &quot;stack&quot; which is somewhere between a commit and a branch, a group of commits.<p>- Better UI, especially for Github notifications.<p>The end result is he feels safer using advanced git features and can move faster, especially when working within a team of multiple devs.

Really depends on &quot;what&quot;.<p>I use a wiki which internally uses RCS, but you never see it. The only reason I even know is that I needed to scan older versions of some assets and it was straightforward compared to what you&#x27;d expect with Git. (Other bonus, attachments and meta pages are stored as actual files. With a little bit of code you can cobble together an automated page builder for e.g. physical assets.)<p>I consider rsync --link-dest a version control system.

Solved is a strong word. For most people, especially with git-forges geing so popular, yes.<p>But if you are doing binaries, because you are an artist&#x2F;do 3d modeling, you probably sill use svn.<p>And I am still checking in on <a href="https:&#x2F;&#x2F;pijul.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;pijul.org&#x2F;</a> from time to time

Yes, I think that we can do better than plain text as the source of truth, and thus git would probably need to change.<p>There&#x27;s work around a bunch of languages that are not based on text, some have their own editor or a tool to manage a canonical representation in text for you that would make them friendlier to git.<p><pre><code> - https:&#x2F;&#x2F;github.com&#x2F;yairchu&#x2F;awesome-structure-editors&#x2F;blob&#x2F;main&#x2F;README.md</code></pre>

IMO Git&#x27;s central enabling technology was disk space getting so cheap you could afford to have a copy of the entire repository and all it&#x27;s history locally. I&#x27;m not sure what the next iteration of that would be... maybe always-on networking, so you&#x27;re constantly consuming changes from all collaborators without having to manually pull them? What useful things could we do with that information?

I feel like git is poorly thought out. If a group of dedicated smart people set out to build a version control system, I doubt they would end up with git.

Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now.<p>The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI&#x2F;patterns (<a href="https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit">https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit</a>, <a href="https:&#x2F;&#x2F;github.com&#x2F;arxanas&#x2F;git-branchless">https:&#x2F;&#x2F;github.com&#x2F;arxanas&#x2F;git-branchless</a>) and smart merge resolvers (<a href="https:&#x2F;&#x2F;github.com&#x2F;Symbolk&#x2F;IntelliMerge">https:&#x2F;&#x2F;github.com&#x2F;Symbolk&#x2F;IntelliMerge</a>, <a href="https:&#x2F;&#x2F;docs.plasticscm.com&#x2F;semanticmerge&#x2F;how-to-configure&#x2F;semanticmerge-configuration-guide#HowtoconfigurewithGit" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.plasticscm.com&#x2F;semanticmerge&#x2F;how-to-configure&#x2F;s...</a>). Git it so flexible, even things that it handles terribly by default, it handles fine with layers: e.g., large binary files via git-lfs (<a href="https:&#x2F;&#x2F;git-lfs.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;git-lfs.com</a>) and merge conflicts in non-textual files by custom merge resolvers like Unity’s (<a href="https:&#x2F;&#x2F;flashg.github.io&#x2F;GitMerge-for-Unity&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;flashg.github.io&#x2F;GitMerge-for-Unity&#x2F;</a>).<p>Perhaps in the future, almost everyone will keep using Git at the core, but have so many layers to make it more intuitive and provide better merges, that what they’re using barely resembles Git at all. This flexibility and the fact that nearly everything is designed for Git and integrates with Git, are why I doubt it’s ever going away.<p>Some alternatives for thought:<p>- pijul (<a href="https:&#x2F;&#x2F;pijul.org" rel="nofollow noreferrer">https:&#x2F;&#x2F;pijul.org</a>), a completely different VCS which allegedly has better merges&#x2F;rebases. In beta, but I rarely hear about it nowadays and have heard more bad than good. I don’t think we can implement this alternate rebases in Git, but maybe we don’t need to; even after reading the website, I don’t understand why pijul’s merges are better, and in particular I can’t think of a concrete example nor does pijul provide one.<p>- Unison (<a href="https:&#x2F;&#x2F;www.unison-lang.org" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.unison-lang.org</a>). This isn’t a VCS, but a language with a radical approach to code representation: instead of code being text stored in files, code is ASTs referenced by hash and stored in essentially a database. Among other advantages, the main one is that you can rename symbols and they will automatically propagate to dependencies, because the symbols are referenced by their hash instead of their name. I believe this automatic renaming will be common in the future, whether it’s implemented by a layer on top of Git or alternate code representation like Unison (to be clear, Unison’s codebases are designed to work with Git, and the Unison project itself is stored in Git repos).<p>- SVN, the other widespread VCS. Google or ask ChatGPT “Git vs SVN” and you’ll get answers like this (<a href="https:&#x2F;&#x2F;www.linode.com&#x2F;docs&#x2F;guides&#x2F;svn-vs-git&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.linode.com&#x2F;docs&#x2F;guides&#x2F;svn-vs-git&#x2F;</a>, <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;875" rel="nofollow noreferrer">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;875</a>). Basically, SVN is easier to understand and handles large files better, Git is decentralized and more popular. But what about the differences which can’t be resolved by layers, like lazygit for intuition and git-lfs for large files? It seems to me like even companies with centralized private repositories use Git, meaning Git will probably win in the long term, but I don’t work at those companies so I don’t really know.<p>- Mercurial and Fossil, the other widespread VCSs. It seems these are more similar to Git and the main differences are in the low-level implementation (<a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;892688" rel="nofollow noreferrer">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;892688</a>, <a href="https:&#x2F;&#x2F;fossil-scm.org&#x2F;home&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v-git.wiki#:~:text=Both%20Fossil%20and%20Git%20store,emphasis%20on%20the%20entire%20DAG" rel="nofollow noreferrer">https:&#x2F;&#x2F;fossil-scm.org&#x2F;home&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v-git.wiki#...</a>.). It actually seems like most people prefer Mercurial and Fossil over Git and would use them if they had the same popularity, or at least if they had Git’s popularity and Git had Mercury or Fossil’s. But again, these VCSs are so similar that with layers, you can probably create a Git experience which has their advantages and almost copies their UI.

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’ve worked with git since 2016. I guess I must not be a power user because beyond using like six got commands I’ve never had any issues or felt like man my workflow is interrupted.<p>What features do you think need to be improved? From a purely UX pov I think git is probably the best software I’ve used. It just works.

Git has problems but is mostly alright, cli aside.<p>Git as practiced by GitHub and gitlab is <i>awful</i> quite a lot of the time.

I&#x27;m sure we can, the question is, can we make an alternative to GitHub? I wouldn&#x27;t be surprised if there are already several better ones, but I&#x27;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.<p>If it doesn&#x27;t have multiple clouds providers with pull requests, and at least one of those clouds providers isn&#x27;t a megacorp, it probably won&#x27;t be the safe boring choice, unless it&#x27;s fully P2P.<p>It needs to be packaged in distros, have GUI integrations, etc.<p>Fossil looks really cool, I really like how they integrate the wikis and issues. But I don&#x27;t know anyone who uses it, and the cloud providers seem to be smaller &quot;Could go away any time&quot; companies.<p>I&#x27;ve never really explored any other VCSes, because none ever seem like they&#x27;re going to be serious competitors.<p>I&#x27;d be more interested in enhancing Git, but it seems a lot of the most interesting git plugins and extensions aren&#x27;t updated, like GitTorrent.

I hope so! After years of using git, I&#x27;m come to the opinion that it&#x27;s far from a great solution. Arguably, it&#x27;s not as good as some of the vcs it replaced. Hopefully, something better will be coming in the future.

There&#x27;s a sweet spot between simplicity, feature and usability. I think git exist right in the middle with a little bit of learning curve.<p>A lot of proposal in this thread would have improved one of these at huge detriment of others.

It would be hard to get past the network effects. Just like how we are stuck with SMTP, JavaScript, PDF, HTML, etc.<p>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).

Yes! In my bubble, we just need &quot;code snapshots&quot; or versioning, but not for the whole repo, more for each function &#x2F; file. It&#x27;s surprisingly hard to get juniors into git, there are so many crazy situations all the time.

I think git has become the standard now. I used git as the reference point when I had to implement a custom version control system for a product . Also many things can be built on top of git, like GitHub for instance

I bet we probably could<p>But you could also do better than Linux or OSX as an OS, but the mindshare and industry investment there is so strong, moving to a new thing is a monumental undertaking

I think the nomenclature could have been better, and less technical people would use it. Calling it commit when it’s essentially a save is good start . Yes I know it isn’t exactly the same as saving but who cares.

I want something simpler than git, with <i>less</i> features, less commands, but far easier to use and covers 99% of use cases, preferably a GUI. (No, simple git guis do not exist.)

Got works great. The main pain point for me is largr binary files. There is git LFS, but it isn&#x27;t default and takes some configuration.

Related <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15206339">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15206339</a>

The prevalence of squashing is a symptom of some kind of problem, and we need a less permanently destructive solution.

Have heard of some FAANG (meta, google..) moving to Mercurial. Any merit in that?

git : version control :: vim : editors<p>There is definately scope for a beginner friendly UI&#x2F;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.

&gt; Or is it a solved problem and Git is the endgame of VCS<p>I&#x27;ve read so many comments to the effect that &quot;X is a solved problem&quot; when it clearly wasn&#x27;t that I&#x27;ve come to conclude that the phrase means the opposite of its surface value...<p>I&#x27;m pretty sure that Git is not the end-of-line as far as VCSs go. Whether <i>I</i> will ever change my VCS, again, ever, that is an entirely different question. I&#x27;ve been through so many of them (RCS; a bit of CVS; a bit of Subversion which promised to be CVS-without-the-flaws, which it was not; Mercurial, because hey it was written in Python, so must be good, right? right?; <i>finally</i> Git; and of course the usual `report-v4-revision-good-one.doc` renaming game; plus a plethora of backup solutions, some really bad ones among them)—so <i>many</i> of them I&#x27;d be loathe to switch to yet another one, except <i>maybe</i> Fossil, which I almost did.<p>So yeah, I had totally forgotten about <a href="https:&#x2F;&#x2F;fossil-scm.org" rel="nofollow noreferrer">https:&#x2F;&#x2F;fossil-scm.org</a> ; the reason it didn&#x27;t become my go-to solution is probably mainly the fault of github.com, which I find too good to be ignored, and I don&#x27;t want an &#x27;impedance mismatch&#x27; between my system and their system. But maybe it would be doable and maybe Fossil is good enough to be worth it; at any rate, go read their docs, especially where they compare themselves directly to Git and give lots of good reasons for their way of doing things. This is the same people who are doing SQLite, so I&#x27;d say a trustworthy source of reliably top quality software.<p>Other than that, my personal way of dealing with the complexities of Git is to avoid using parts that I don&#x27;t need or don&#x27;t know about well enough (i.e. almost all of it). I use it to check in changes, give one line of comment, and upload to github.com; then of course cloning and updating existing repos as well as setting up a new ones is within my skill set. Branching and merging not so much. So it&#x27;s like `git` plus `clone`, `add`, `commit`, `push`, that&#x27;s all; also, I use Sublime Merge for part of these (reviewing changes, adding related changed chunks, commit) which I must recommend for the piece of fine software that it is.<p>I also at some point toyed with gitless (I think it was called) which promised to be Git, but simpler for the simple things and you can always fall back to Git proper where called for; this I find a good proposition that I like (Markdown: fall back to HTML; CoffeeScript: fall back to JavaScript) but somehow gitless didn&#x27;t stick with me; I <i>guess</i> that&#x27;s b&#x2F;c I&#x27;ve already tempered down my usage of Git to a point near absolute zero, and command line history + Sublime Merge does the rest.

To me, &quot;Could there be something better than git?&quot; is not the important question.<p>What matters is if git is good enough.<p>Or more specifically, is if git good enough for X when X is something that is actually being done.<p>I mean, git is good enough for my very minimal needs and the needs of people with much more sophisticated needs than mine (e.g. the Linux team). And since I know more about git than any other VCS (in part because there are better resources for learning git than any other VCS) learning another VCS for the sake of learning another VCS wouldn&#x27;t help me get anything done.<p>None of that means git is good enough for your needs, but statistically, it probably is good enough for your needs because statistically, most difficulties with git are related to training and knowledge since the mathematics underpinning git are (to the best of my understanding) sound.<p>Which also implies (not accidentally) that being better than git requires better resources for learning the new VCS than git has, and that&#x27;s a very tall order.<p>Good luck.

The best feature of Git is that it’s used virtually everywhere. I don’t really care about anything else, I just know I won’t contribute to a repo if it doesn’t use Git.

Yes, its called mercurial

No, git is perfectly fine. You just need to study it to master it, just like every other tool we use in our craft.