31 ms·

Is Git Irreplaceable? (2019)

240 points by cnst 7y ago

rhabarba 7y ago
Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that the IT world has mostly decided to settle with whatever is the most commonly used right now, no matter if it is actually the best solution - so at least when it comes to DVCS, the war seems to be over.
- StavrosK 7y ago
  How does that interaction work? Last I checked, it wasn't great or it was too much of a hassle (I don't remember exactly).
  - rhabarba 7y ago
    Exporting to Git: You set a "Git mirror" once, optionally with a remote URI, and call fossil's export routine. Example: I wrote a cronjob that runs once every night that does nothing but update my Git mirrors from the current Fossils. cd $FOSSILDIR for f in *; do /usr/local/bin/fossil git export -q -R $f done Importing works... similarly. :-)
    - StavrosK 7y ago
      Hmm, but does importing keep all your issues, etc? I imagine it just imports the new commits?
      - rhabarba 7y ago
        Fossil cannot import things from Git which Git does not store. Git has no issue tracker.
        StavrosK 7y ago
        Right, but are the local Fossil issues preserved during import?
        rhabarba 7y ago
        Sure.
        rhabarba 7y ago
        ... (I guess. Need to test that.)
- 0_gravitas 7y ago
  But this doesn't hold for things like languages, adoption of new tech over old (no matter how prominent it is) happens all the time, but it usually starts at the small scale, like start-ups. It definitely takes a hell of a long time, and it would probably never usurp 100% of gits usership (or even 50%), but it will probably be used in some capacity. Of course Java's still as big as ever, but we have seen an uptick in relatively new languages still coming into use (I think of things like Elm/Elixir).
  - int_19h 7y ago
    There was always an "uptick in relatively new languages coming into use", as long as I remember. The problem is that most of them die before they mature, and some achieve a "peak cool" but then fade into obscurity, or find a relatively small niche. Very few new languages ever get popular enough to get into the top 10 on a permanent basis, and even fewer displace a large player that was previously popular. Meanwhile, most code running on any given computing device is still written in C, C++, or Java. The article is basically arguing that we're likely to see the same state of affairs in VCS land. Sure, there will still be new ones coming into use, and fading out, or finding small niches - but Git will remain dominant for decades to come.
- theamk 7y ago
  Does not Fossil’s “no rebases” philosophy bother you? IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.
  - SQLite 7y ago
    https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
    - theamk 7y ago
      Right - and I think that point 6 and 7 are exactly why I use rebase daily, and why I will never use Fossil. The version control history is made for reading by other people, so it is a story. After all, we only write the commit once, but people will read it many more times. (This is especially true if there are code reviews involved) I am an imperfect programmer. My work-in-progres is often broken, and even fails to compile. Sometimes I will refactor interface only, and will want to checkpoint my work before I go and refactor implementation as well. Sometimes I will choose a totally wrong approach and revert it later. Sometimes I will disable/break large part of system on purpose, to make testing easier. And I often do stupid data-destroying mistakes, so I want an ability to save/store all the past versions, even if they are completely broken. My “raw” commits may look like: “start on feature X”, “refactor interface Y”, “more work on feature X”, “wip commit”, “fix tests”, “fix performance”, “fix more tests”. Does any future reader care it took me 3 commits to get the tests right? Do they care that I discovered the need to refactor only while I was halfway in feature X implementation? Do they want to see a repo that won’t even compile? Do they want to hav to cherry-pick dozens of commits to get the tests to pass? I don’t think so. The final version will only have two commits, “refactor” and “feature X”. It would be obvious to everyone which lines of code are associated with which change. Each revision will be buildable, and will pass all tests - so bisect will actually work. (If rebase support is missing, it is possible to “fake” it by having multiple checkouts and manually copying files around. But this is much more error prone and dangerous. I have spent plenty of time with SVN/CVS, manually copying files and applying patches - and I can tell that having this integrated with version control is much more pleasant)
oxfordmale 7y ago
Git can easily be replaced in my company if there was business need for it. For now it does do its job, but there is no reason we wouldn't migrate if there was a better alternative. Right now there isn't one.
- rhabarba 7y ago
  Which features would make it for you?
  - enjo 7y ago
    Perforce is still in use in content heavy industries because Git still struggles with large binaries. Something with git branch semantics that could handle those files would be huge.
    - emodendroket 7y ago
      Isn't that what Git LFS is about?
      - sergiotapia 7y ago
        This is funny, this exact same conversation happens on hn at least once a month. Reply for reply same convo
      - Aeolun 7y ago
        Yeah, but it’s not really out of the box.
    - m463 7y ago
      I actually like perforce. (if you're not constrained by distributed) It does huge well, and I like the one-number changelist.
      - jayd16 7y ago
        I really miss being able to check in chunks instead of full files, and streams are a poor replacement for git branches but it does let you do monorepo. P4V is a buggy mess though.
thenewnewguy 7y ago
I find it ironic that in the same post the author complains about a git monopoly ("Git effectively has a global monopoly on DVCSes") while wishing the same thing for fossil ("Fossil's world domination will not come from...").
- lidHanteyk 7y ago
  "world domination", specifically, refers to a long-running joke about the corporate-sponsored capitalist competitors to FLOSS. See [0] for an example of the joke being used to title a talk and frame business decisions. [1] contains a history of the phrase in the Linux world. Note that Linux and git share the same original author/designer. [0] http://www.catb.org/~esr/writings/world-domination/world-domination-201.html http://www.catb.org/~esr/writings/world-domination/world-dom... [1] http://xent.com/pipermail/fork/2002-January/008429.html http://xent.com/pipermail/fork/2002-January/008429.html
consultutah 7y ago
SVN seemed irreplaceable not so long ago and CVS before that and RCS before that... When someone comes up with something demonstrably better and gets the right people to start using it, people will switch over.
- rhabarba 7y ago
  Note how POSIX still has SCCS as the default VCS (and it is still fine for single file commits)...
- colechristensen 7y ago
  SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
  - emodendroket 7y ago
    I mean so is Unix and it's still around all these years. Heck there's nothing especially obvious about a for loop, yet every language has them. Once everyone's accustomed to the weird interface they are just going to demand everything else have the same weird interface they're used to. This is one of the lamentations of the Unix Hater's Handbook.
    - wwright 7y ago
      If you’re talking about a “for (initialize; condition; step) { body }” for loop, most newer languages don’t have them AFAICT. I would say the other kind of for loop, a “for x in y { body }” loop, is very intuitive and obvious to most English speakers. We use idioms like “for each A, do B” all the time.
      - emodendroket 7y ago
        I meant the C-style one and they do appear in most commonly-used languages, though I guess most commonly-used languages are not all that new.
dustingetz 7y ago
The cloud is going to change a lot of stuff, file-system based code might be gone, code-in-database is already halfway here ... opportunity
- krasin 7y ago
  I agree with the first half of the statement: we indeed do not have a cloud-first version control system. It could bring some real benefits of tight integration with continuous build and other things considered to be essentials nowadays. I don't see files going anywhere. I would like to listen to examples of "code-in-database is already halfway here", if you happen to have them.
  - dustingetz 7y ago
    My startup is one http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ Others are https://darklang.com/ https://darklang.com/ and https://www.unisonweb.org/ https://www.unisonweb.org/ and of course scripting google sheets with javascript Low-code is very suddenly going to be a big thing in the next couple years and when it happens there are now 750M more "coders" and those types of people are not interested in git pull --rebase --fucked --whatdidido
    - krasin 7y ago
      Thank you, very interesting pointers!
  - wtetzner 7y ago
    Of course, you could probably build some pretty convenient cloud-syncing tech on top of Git without a ton of effort.
- agumonkey 7y ago
  tree diff over graphql
  - dustingetz 7y ago
emodendroket 7y ago
I am happy to use whatever everyone else starts using, provided it works at least as well. But I also do not have many problems that git won't solve, so I don't feel a burning need to switch. I think git is good enough that source control is no longer a very interesting problem.
- ken 7y ago
  But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
  - emodendroket 7y ago
    When I started developing the options people were taking seriously were Mercurial and git. At first I was using mercurial, but since everyone else was using git I switched to that. So those are the only ones I've seriously used.
  - EdSchouten 7y ago
    I don't think there are many people that considered CVS good enough, even back in the days. For example, there was no way for end-users to retain the history of a file when renaming/copying it. When the FreeBSD project still used CVS, committers always had to file tickets against the admins to ask them to do it server-side through a so-called 'repocopy': https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080
  - jerf 7y ago
    Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all. There were several times there were builds that were completely unreproducible because it turned out that they were, technically, r83726, except this directory was r84713, but this other directory was r78372 except for a subdirectory that was r84299, etc. That problem I saw even before I saw a replacement. But once I saw git, having a full copy of the repo was pretty killer. It was also better at merging, partially for having the history local. In fact I recall some SVN people protesting at the time that merging wasn't so hard, but in a nutshell, they were just wrong. It was harder. Source control that can't merge fluidly is pretty limited from the get-go. There's literally entire dimensions of things we do with git that were so impractical with SVN that only the very largest projects could afford to do them, with the whole "workflow" question. Now you don't even hear about the difficulties of merging since all the open source SCMs copied each other and "good merging" is just table stakes now. The problem is is that git doesn't really have fatal flaws, it has annoyances, and that's not the same thing. "The UI is difficult" is an annoyance for its target audience. Most every other criticism I've seen of it is an annoyance, not a fatal flaw. Fossil doesn't solve a problem I have with git. It has some neat ideas and arguably does solve some problems, but it doesn't solve the problems I have with git; you could lift Fossil's solutions to wiki and bugtracking and just put them in Git and I'd probably be happier with that than Fossil itself. The problem isn't that Fossil is an SCM competing with git; the problem is that Fossil is a monolith competing with the rapidly-moving git ecosystem. The former is perhaps beatable, the latter is a juggernaut. All of Fossil's other features sitting in git is something that might get somewhere, but if the base source control isn't git-based, I can't sneak it into a work project to try it out. I've got a corporate mandate that all source belongs somewhere standard, and it's a perfectly sensible requirement for someone paying me to do a job.
ken 7y ago
Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.
- dickjocke 7y ago
  Can you explain more about that? I've worked with both and I feel like monorepo is kinda a pain, but I dont understand where Git fits in to either directly. Seems like it just snapshots files.
  - Skunkleton 7y ago
    In this context "monorepo" means a huge repository with many many revisions. Git has several well documented deficiencies in this scenario. See [1] for microsoft's experiences with git. [1] https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
  - chubbyrabbit 7y ago
    It's only a problem at a really large scale. At the scale of Microsoft or Facebook, there are factors that lead to the use of a monorepo being more efficient. At that big of a scale, companies have enough resource to develop internal tooling to deal with the problem (e.g. the use of Mercurial at Facebook).
    - gatekeeperthrow 7y ago
      It would be nice if you and everyone else stopped gatekeeping this problem. We have 600 devs and face these problems. I can assure you we sure as hell dont have the resources spare to reroll git. We're way too busy rerolling everything else.
    - int_19h 7y ago
      FWIW, in case of Microsoft at least, it's more a question of product size than company size. Microsoft doesn't use a single monorepo for everything, like Google (so far as I know) does - just look at http://github.com/microsoft/; http://github.com/microsoft/; and that's not even counting all the VSO repos! It uses product-specific monorepos for some large products.
l0b0 7y ago
It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the current contenders. Git made it possible to run VCS without a separate server program and sped up VCS operations massively. Both of those were huge. Looking at the Fossil home page[1] it does have some features I personally have wanted in VCSes, such as integrated "bug tracking, wiki, forum, and technotes," but the devil is very much in the details of how that actually works (How easy is it to write your own custom frontend or add business-critical bug tracking fields, for example?), and it's not like we don't already have good bug trackers, wikis etc. Just as a tangent, some issues (but not necessarily major or fundamental, depending on who you ask) with Git as it works right now: - Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. - Git Annex is not yet built in. - The command line is complex, including many niche subcommands and tons of rarely used options. - The command line is inconsistent, such as `git rm` vs `git branch --delete` vs `git remote remove`. - It is based on a less than ideal theoretical model of patches[2]. IMO this is the most exciting development in VCSes since Git. [1] https://fossil-scm.org/ https://fossil-scm.org/ [2] https://pijul.org/model/ https://pijul.org/model/
- rhabarba 7y ago
  > unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.
  - wtetzner 7y ago
    How so?
    - rhabarba 7y ago
      Less overhead, a better UI.
JohnFen 7y ago
Of course Git is replaceable. When a new tool that provides a substantial benefit over using Git comes around, it will be replaced. If that never happens, then it's a pretty strong indication that Git is working perfectly fine -- so why worry about whether or not you can replace it?
zestyping 7y ago
It feels that way, and it's heartbreaking that our entire species ended up locked into a tool with such a horrible interface. In a way, the git monopoly is worse than Windows or x86 or IPv4, because it's not just a piece of technical infrastructure. Its arcane commands and its branching model have infected all of our brains. You can choose a different editor, you can choose a different operating system, but for as long as we all live, we will never escape the fact that "git reset" does a half a dozen confusingly different operations, or that renaming cannot be tracked, or that most users don't fully understand most of the commands they regularly use.
- Skunkleton 7y ago
  Check out new versions of git. The overloaded checkout and reset commands are being phased out to some extent.
pbiggar 7y ago
I'm working on a git replacement, in a way. The thing that makes git powerful is that its just text. Git is probably the most powerful thing for code as text. When code no longer is just text (and by "text" I mean bytes on disk, not that we're switching to coding with emoji or VR) you get to do more powerful stuff. Our plan in Dark (https://darklang.com https://darklang.com) is to combine all the different ways that people "branch" (deployment, feature flags, git branches, staging/dev/prod environments) into a single concept. And then we also plan to combine all the ways to "comment" (PRs, slack messages, commit message, code comments) into a single concept. Not sure if you'd call that a git replacement, but it's a displacement of sorts - the function of git is replaced by non-git.
- zestyping 7y ago
  Sounds intriguing! Can you say more about what that single concept is and how it works?
  - pbiggar 7y ago
    To be clear, it's two concepts, one for branches and one for comments. The first concept we've been calling deployless, and discussed it here: https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671 https://medium.com/darklang/how-dark-deploys-code-in-50ms-77... The second one is just an idea right now, suggestions welcome. The observation is that comments on a particular line of code are spread in as many as a dozen places (a google doc, slack, trello, the code itself, an old version of the same code, PRs on github, comments on commits on github, commit messages, another place in the codebase referencing this one, the docs folder in your repo, another repo that uses this API, your 3rdparty docs on README.io, etc). This is weird and bad, and it must be possible to do better.
    - shalabhc 7y ago
      For comments, fully agree that we don't need several isolated systems (source files, docs, commit messages, ...) How about one system which is a hypermedia system and can hold many different kind of objects. So annotation objects can reference 'code objects' such as types, fields, functions or even blocks directly. Not sure if Dark gives each of these an identity (it should) which will make it possible to refer to them via hard links rather than text snippets. Once you have all code and comment objects in one hypermedia system, creating views from that is about multiple projections of the interconnected objects. Wouldn't it be great if I can use a query to refer to 'all functions that reference this type' inside some docs? Or list all annotations that reference a function? These could be embedded inside annotations as well. Gtoolkit does something similar. Perhaps even a 'branch' can be thought of as a subset of the hypermedia graph. E.g. using a code block X2 instead of a code block X1 within the same function.
DecoPerson 7y ago
> 1. Metcalfe's original Ethernet has been replaced a bunch of times... These replacements were seemless to users. New Ethernet adapters were compatible with at least the previous spec. The Git import/export of Fossil is not seemless at all. It actually adds quite a bit of complexity if you want to introduce it your regular workflow. > 2. Microsoft's long-term stalwarts Windows and Office are dying... Citation needed. > 3. Adobe's having a hard time hanging onto its old market... Citation needed. > 4. IPv4 still won't go away... There is a lot of hardware out there that only works with IPv4. The costs and risks of switching your org's internals, product or services from IPv4 to IPv6 are phenomenally higher than switching your org from Git to Fossil or adding Fossil support to your product or service. If Fossil is truly superior to Git and people are not switching to it, then there's no hope they'll switch to IPv6. Not until the cost of not switching is greater.
- chx 7y ago
  > These replacements were seemless to users. Not at all. I remember how long it took for Cat 5 to replace thinnet.
- fulafel 7y ago
  Wifi mostly replaced ethernet for user facing applications. There was partial protocol compatibility between ethernet and wifi, but the user experience was very different. Some features were lost or degraded (eg speed, reliability, security, configuration complexity) but a pain point (cables) was fixed.
rurp 7y ago
I really doubt Git is going anywhere for the foreseeable future, but I could imagine a more approachable VCS catching on. Git is extremely opaque to most new developers and even for experienced devs looking up a new command. Sometimes I look up how to perform an unfamiliar task with Git and find 4-5 competing answers on Stackoverflow with no real clear explanation of why one is better than another. If an easier VCS caught on enough to be used in schools and boot camps, many younger devs would start with that one and just keep using it as they progress in their career. The new VCS wouldn't have to be better or more powerful, just easier to use for the basic stuff that makes up 95% of Git usage, in order to gain traction. That said, Git works perfectly fine and is so entrenched that I don't see it going anywhere.
- roca 7y ago
  Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there was a better one. I don't think there is.
  - HALtheWise 7y ago
    The obvious pool of people who don't currently use VCS's is everybody who mostly deals with files that aren't plain text. Using git to collaborate on Photoshop documents, Word docs, Jupyter notebooks, videos, or any other non-plain-text format is a frustrating nightmare, and a VCS solution that provided revision tracking and collaboration for all those filetypes would open up a new set of users.
    - james_s_tayler 7y ago
      Just use SharePoint.
  - spderosso 7y ago
    However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS I think this is true if you think the target market for VCSs is professional software developers only. But there are other people writing code that might care less about the fact that Git is the standard for professional software development and don't want to pay the cost of learning or using Git: data scientists, scientists in general, new media artists, most high school students, etc. I've had a hard time selling Gitless (https://gitless.com https://gitless.com) to undergrad CS students, but it is easy to sell to non-CS students that write code. That said, GitHub is a big thing so any new VCS probably needs some story for Git-compatibility. Even tools that have built-in version control like Overleaf have some way of synchronizing with Git repos.
comex 7y ago
Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) leaky abstraction. Microsoft's GVFS is a promising attempt to truly scale Git to giant repos, but it's developed as an addon rather than a core part of Git, and so far it only works on Windows (with macOS support in development). GVFS arguably has the potential to become an ubiquitous part of the Git experience, someday... but it probably won't. Git also has trouble with large files. The situation is better these days, as most people have seemingly standardized on git-lfs (over its older competitor git-annex), and it works pretty well. Nevertheless, it feels like a hack that "large" files have to be managed using a completely different system from normal files, one which (again) is not a core part of Git. There exist version control systems that do scale well to large repos and large files, but all the ones I've heard of have other disadvantages compared to Git. For example, they're not decentralized, or they're not as lightning-fast as Git is in smaller repos, or they're harder to use. That's why I think there's room for a future competitor! (Fossil is not that competitor. From what I've heard, it neither scales well nor matches Git in performance for small repos, unfortunately.)
- james_s_tayler 7y ago
  I'd say the number of git repos on Earth that would encounter problems of that nature would be a vanishingly microscopic minority. Sure, it's a problem for those companies but it's not a problem for anyone else.
  - hamandcheese 7y ago
    Vanishingly small in number, but quite significant in terms of the number of developers working in them.
    - Polylactic_acid 7y ago
      All of the organizations that have outgrown git will have such incredibly specific requirements meaning nothing but a custom built tool will work for them.
romwell 7y ago
When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify the code before the commit gets checked in. The history of the comments and changes should be maintained. There is nothing in Git that supports this flow in a natural way. A replacement for (or evolution of) Git can be a tool that would support this code review flow from the get-go. And yes, there are external tools for code review. But that all should be a part of version control.
- tick_tock_tick 7y ago
  I think it doesn't exist because there is no demand for that to be part of the codes history. Nothing you've described sounds very useful after a month or so.
  - romwell 7y ago
    Sure, but keeping that history is just a small part of what I said. The point about code review still stands.
    - rhabarba 7y ago
      That's the one major point where Fossil probably falls short: Extending a repository's capabilities would add overhead to every single one of them (and, potentially, to each commit's meta data).
  - pbh101 7y ago
    All this talk of Git-sympathetic code review tools and nobody has mentioned Gerrit, which seems at least somewhat close to what is being described. Each patchset of each review is its own Git ref and is often referenced in the final commit. Separately, I know many including myself who would love for code review comments to more seamlessly be integrated into the code browsing experience.
vfclists 7y ago
When they say Git, isn't Github and Gitlab they actually mean?
sys_64738 7y ago
Git is a tool to get the jobs done, not a religion.
kjgkjhfkjf 7y ago
Eventually git will be replaced by something better. It might not be replaced everywhere, but eventually it will be replaced in most places. This is true of almost all things in tech. I expect that git's eventual replacement will initially boast compatibility with existing git repos.
- pg_is_a_butt 7y ago
  Anything that could maintain compatibility with git repos after an initial import process couldn't possibly be any better than git.
taspeotis 7y ago
If you take a look at Subversion vs. Git's interest on Google [1] and you agree it has some correspondence to the technology adoption lifecycle [2] ... Git's got a long way to go. [1] https://trends.google.com/trends/explore?date=all&q=%2Fm%2F012ct9,%2Fm%2F05vqwg https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... [2] https://en.wikipedia.org/wiki/Technology_adoption_life_cycle https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
734129837261 7y ago
I wish there was a version control system that didn't need user input beyond a "push". Only branches and pull requests, nothing more. No commit messages, you have one master branch and however many sub-branches you need. Whatever code is in your branch is what it is. And then there's a layer of magic on top of it all, maybe a UI or command line tool or both, just to be able to easily rewind time. Either per file, per line of code, or folder, or just a folder but not recursive, or the entire branch. Think of Apple's Time Machine, it should be that simple. Honestly, I rarely–if ever–read commit messages to begin with. The way I navigate older code is never done by searching for commit messages. That's not reliable. Instead I simply go to a point in time where I think the thing I'm looking for might be. I'll look at the code, recognise its state, and continue the search up or down the timeline. And that would cover the needs of most projects I'd say. And it would save us a shitload of time. Hell, I've been working with git for almost a decade now. I never needed to rebase or merge things, until I recently did need to do it. It's too arcane to make intuitive sense, to me anyway. Git is good, I'd just welcome a breath of fresh air...
- tenken 7y ago
  Do you work on a team? Or in a job were you need to have an audit trail for your work? Commit messaged and many other features of Git like branching and tags are indespensible for sharing and collaborating on code.
  - eesmith 7y ago
    Flip your questions around. Might someone who isn't on a team, and doesn't need an audit trail, want something simpler? Versioned files systems, including Apple's Time Machine and Dropbox's version history, have no extra UI to save versions. A small, short-lived project with at most a few collaborators (eg, working on a small scientific paper) might find those more useful than git or other VCS.
    - at_a_remove 7y ago
      I would have to agree with this. I have been programming for decades and I haven't had to work on a team for a project. "Branches" have not happened, nor have I ever felt the lack of them. I would not mind something simple. I find the arguments, flags, whatever in git to be rather opaque. That, coupled with the lack of need for its features, have not thrilled me. It seems to be pretty effective if you have tons of programmers working on a single project, but at the bottom end of the scale, I find it baffling.
harry8 7y ago
Taking the question literally, obviously not. If git became a problem due to some unforseen licensing issue or whatever mercurial does the job just fine right now and has for years. As a heads up if you're stuck on cvs, svn or other stupid vcs due to "old-codgers" in your office, mercurial has a shallower learing curve and easier ui to get the same job done which may make it easier to switch. Either git or mercurial, who cares? Either of them until there's something better. Never deal with SVN & CVS branches and merges again. Feel the immediate team productivity boost which will pay for the initial learning curve costs by day 2. Seriously.
- choeger 7y ago
  > day 2 Unfortunately, you have to settle on some workflow for that. And this settling will take some experience and discussion. So "day 2" sounds very overambitious to me.
  - harry8 7y ago
    Use the existing svn/cvs workflow with the trivial changes for git/mercurial. Central repo, push when you're done to master. Branches are all but unusable on cvs/svn anyway - if you do use them, feel the win and laugh with glee. When everyone is on top of that basic workflo then you do something incrementally better. Really it's day 2, really. I've seen this more than once now. The fight to get to that point where the changeover happens is getting easier but I'm sure it still sucks.
HALtheWise 7y ago
One major fundamental issue with git that nobody has brought up is that its data model is close-to-incompatible with some of the current legal and moral requirements around data privacy today. For example, as far as I can tell, GDPR allows any European citizen who has ever committed to the Linux kernel to request that their name be permanently expunged from their contributions, and everyone with a git clone of the kernel is legally obligated to perform a rebase to do so. It's possible to make a DVCS where that is an easy operation, but git very much isn't it. That means it can't be used to store personal data, and even standard corporate policies of "we delete old historical records so they don't bite us in court" aren't supported. There are definitely times you want to store the full history forever, but it would be nice to have a DVCS that gave other options.
- 0xff00ffee 7y ago
  Like when I accidentally check in credentials. /insert Michael Cain playing Homer sound: Buh-oh./
- GauntletWizard 7y ago
  The legal requirements in the EU are at odds with the moral requirement. Changing or erasing history in Git is an anti-feature. Checked in secrets should be assumed to be compromised and changed immediately. Removing contributions should be treated as any other form of censorship. Those who forget (or rebase away) history are doomed to repeat it.
- fsh 7y ago
  Could you cite the paragraph of the GDPR that requires this?
kseo3l 7y ago
git has big problem with binary files, hopefully a new technology can fix that
ChuckMcM 7y ago
Does Fossil do sub-modules correctly? Specifically does it let you compose a project of several repositories and do configuration management on that repository? That is something git kinda sorta does but it gets out of control easily.
- hinkley 7y ago
  I like the idea of storing commit history in a database. Why write all of the bits from scratch? But I don’t like how difficult databases make it to represent graphs of data. To pull a subtree cheaply, you need a graph. not unlike SVN’s data structure.
  - swish_bob 7y ago
    Use a graph database?
- jldugger 7y ago
  Is this something you want in a VCS, or can it be adaquately handled by something like myrepos?
  - ChuckMcM 7y ago
    It is something that I prefer to have in a VCS. At one end of the spectrum you treat a repository as a object which a containing repository can subclass with specific changes. Such a system would allow things like basic driver frameworks for a bunch of devices to be in their own repository and the 'critical bits' that make them work in a system of type 'x' would end up being a that repository + changes. You can kind of do this with git where you create a branch for each system x, y, and z in the repository and then your submodule is driver repo branch x but that doesn't put the maintenance burden in the right place (the system X maintainer).
- rbehrends 7y ago
  Fossil's intended use case is different from Git's; it was originally built as the VCS for SQLite. In terms of its target audience, it's basically GitHub-in-a-box for small or medium-sized teams. Implementation/usability-wise, it does some things better than Git, does other things worse, and yet others simply different (in a way that some may find better, some may find worse).
interfixus 7y ago
For what it's worth, the linked page is itself running on Fossil, which has of course build in forum facilities and several other suchlike goodies - being a complete solution, packed into a single smallish executable with no significant dependencies apart from SQLite. The Fossil site runs on very moderate hardware, and gets no hiccups from hitting the HN frontpage. I like this kind of untroubled minimalism, and so far have never encountered a reason not to run every personal project on Fossil. The real world will occasionally force me onto Git territory, but I can't really say I have ever enjoyed the experience. Git is here to stay for any foreseeable future, of course. And while I do understand points often made about the benefit of one de facto standard to rule them all, monolithic dominance always tends to unsettle me. My SE friends in general simply use 'Git' as a given synonym for 'version control'. And it does annoy and somewhat worry me that they've never even heard of Fossil until I roll out my sermon.
- petre 7y ago
  We use Fossil as well @work and we love it, although I don't think it's not the best choice for huge codebases such as the FreeBSD ports tree which I tried to import once to see how it scales and gave up after >2Gb and a hour or crunching. Maybe importing into nested repositories would work better?
tasuki 7y ago
> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.
- brylie 7y ago
  The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.
  - kortilla 7y ago
    The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.
    - afiori 7y ago
      Yet no one is doing it.
    - baud147258 7y ago
      > There is nothing preventing you from writing a different front end Or you could just use a tool where the interface is fine out of the box
    - wyoung2 7y ago
      Which is why there are dozens of Git front-ends, fragmenting the market, reducing the benefit of cross-training within a team. "Oh, you can't do that in your TortoiseStudioCodeThingy? I just right-click and select Frobnicate File, and it fixes all that!" Thus editor wars, language wars... Alternative: a tool like Fossil where the CLI is sensible from jump so the whole team doesn't replace it with something better, uniquely per team member.
- matsemann 7y ago
mikl 7y ago
It’s not irreplacable. But it’s very well put together, and a great ecosystem of tooling exists around it. So any potential replacement would have to be a lot better for people to move. And for those of us that remember the dark days of CVS and the pain of migration (I helped migrate drupal.org from CVS to Git), that is a good thing. I don’t miss the days where you had to make difficult SCM choices when starting a new project, whether bzr, Mercural or Git was the right choice. Git has become the lingua franca of SCM, and that is great. So many great developer tools exist that integrate seamlessly because it is safe to assume that 99% of the audience for it will be using Git.
tomesch1982 7y ago
The git internals are good for some kinds of projects but for the actual majority of projects git is a very bad fit. Most people don't get that because they are blind for the much better tools like mercurial and fossil. The git UI/UX on the other hand is the worst piece of crap ware known to man. This piece of shit has probably destroyed more data than any other tool ever written. People who think that git is any good are obviously wrong and can easily proven wrong. It's sad that git has become the default.
- rimliu 7y ago
  How funny, it was actually mercurial that destroyed my repo. Never looked at it again. Also, it is very hard to "destroy data" in git.
- quleap 7y ago
  mod this up
throwGuardian 7y ago
> Microsoft's long-term stalwarts Windows and Office are dying Judged on what metric? Office's paying monthly active users and revenues have consistently grown, measured both quarter on quarter, and year on year
- majewsky 7y ago
  I would probably think the same if I were stuck in my Linux bubble, but $WORK allows me to observe the average computer worker. They're incredibly deep in the Microsoft ecosystem and not at all interested in switching.
jasoneckert 7y ago
Am I the only one who read this thinking "Oh come on....git with the program dude...."?!? Seriously, I love git.
mikece 7y ago
The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to Show HN your ability to implement the same thing in Rust with lower memory and better safety? Awesome! But with Git this isn't possible because there's no concept of the API or interface for distributed version control being separate from the implementation -- and the discussion of "could the API be better than what it is now?" has never been had in a meaningful way.
- crazypython 7y ago
  Isn't its API the file system layout? I use GitUp, which interacts directly with the .git/ folder.
- orf 7y ago
  There is, it's the .git directory. Both the protocol and the directory are well specified. See libgit2 for an example non-reference implementation. I think someone even built an implementation in bash, but I can't seem to find it now.
  - Iwan-Zotow 7y ago
    > I think someone even built an implementation in bash, but I can't seem to find it now. someone named Linus, I guess?
    - orf 7y ago
      No, it was someone exploring git internals by writing a simple git implementation in bash.
- augusto-moura 7y ago
  Of course it has, the other implementation that comes to mind now is JGit [1], a git implementation in Java. A lot of IDEs, build plugins are using it for interfacing with git without the mess that is JNI [1]: https://www.eclipse.org/jgit/ https://www.eclipse.org/jgit/
quadrifoliate 7y ago
I find it amusing that the author mentions Git and Excel in the same breath. One is a GPLv2 piece of software that you can submit patches to, fork, or build your own copy and sell it (so long as you release the source); while the other is a closed-source piece of software that provides largely static utility to many people, yet keeps increasing in price (latest is ~$100/year for an "Office 365" subscription if I remember correctly). Imagine if you had to pay $100/year to use Git. I would probably hand it over, begrudgingly. But the fact that I don't is probably one of the more important triumphs of Free Software over proprietary in recent years.
tzury 7y ago
Bazaar and Mercurial are dying... Bazaar is dead, and Mercurial is near death. Linus wrote the Linux kernel and it became the "de-facto standard" for web application stack servers (and phones, and watches, and Chroemcast and all sort of `Internet things`) Linus wrote git and it became the "de-facto standard" for version control. If a world had 23 more Linuses, we would have full control over our SaaS and "Clouds" and not locked-in as we are at the moment. But we have only one like him.
- alexhutcheson 7y ago
  Facebook[1] and Google[2] have both publicly stated that they are using Mercurial internally, so "near death" seems like an exaggeration. Mercurial has some significant advantages over Git if you want to implement a scalable backend for really large repos. [1] https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... [2] https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
  - BjorksEgo 7y ago
    Theres been plenty of work done to make git enterprise scale in the last year https://vfsforgit.org/ https://vfsforgit.org/
    - alexhutcheson 7y ago
      That's a promising project, but it's currently Windows-only. My main point was that Mercurial is very much "not dead yet!"
- bytematic 7y ago
  It's likely that there are many Linus's but they are not in positions (third-world, poverty, poor parenting, dictatorships) to achieve the same. That's why I think the biggest progress in tech/innovation will come with lifting as many people as possible out of those situations
micimize 7y ago
fossil is a really interesting project, but the switching cost from git is pretty massive. The two killer issues for me: * community/history: any issue I have with git, someone else probably has had. Being a pioneer is very expensive, time wise. * ecosystem/tooling: aside from git host provided tooling, there're integrations for vscode, slack, CI, etc.
lasereyes136 7y ago
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... - Any headline that ends in a question mark can be answered by the word no.
- omarhaneef 7y ago
  Do you mind if I take all your money?
hnrodey 7y ago
Unsure if this is just my hot take but... GitHub is what mainstreamed Git to what it is today. Who knows what our industry would look like (with regards to source control) if GitHub never existed. Probably still SVN and Team Foundation Server (shutter).
pixelbath 7y ago
Absolutely not. Give me something that can more elegantly handle sub-projects and sub-repositories but still works as well as Git, and I'll stop using Git today.

240 points by cnst 7y ago

Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that the IT world has mostly decided to settle with whatever is the most commonly used right now, no matter if it is actually the best solution - so at least when it comes to DVCS, the war seems to be over.

StavrosK 7y ago
How does that interaction work? Last I checked, it wasn't great or it was too much of a hassle (I don't remember exactly).
- rhabarba 7y ago
  Exporting to Git: You set a "Git mirror" once, optionally with a remote URI, and call fossil's export routine. Example: I wrote a cronjob that runs once every night that does nothing but update my Git mirrors from the current Fossils. cd $FOSSILDIR for f in *; do /usr/local/bin/fossil git export -q -R $f done Importing works... similarly. :-)
  - StavrosK 7y ago
    Hmm, but does importing keep all your issues, etc? I imagine it just imports the new commits?
    - rhabarba 7y ago
      Fossil cannot import things from Git which Git does not store. Git has no issue tracker.
      - StavrosK 7y ago
        Right, but are the local Fossil issues preserved during import?
        rhabarba 7y ago
        Sure.
        rhabarba 7y ago
        ... (I guess. Need to test that.)
0_gravitas 7y ago
But this doesn't hold for things like languages, adoption of new tech over old (no matter how prominent it is) happens all the time, but it usually starts at the small scale, like start-ups. It definitely takes a hell of a long time, and it would probably never usurp 100% of gits usership (or even 50%), but it will probably be used in some capacity. Of course Java's still as big as ever, but we have seen an uptick in relatively new languages still coming into use (I think of things like Elm/Elixir).
- int_19h 7y ago
  There was always an "uptick in relatively new languages coming into use", as long as I remember. The problem is that most of them die before they mature, and some achieve a "peak cool" but then fade into obscurity, or find a relatively small niche. Very few new languages ever get popular enough to get into the top 10 on a permanent basis, and even fewer displace a large player that was previously popular. Meanwhile, most code running on any given computing device is still written in C, C++, or Java. The article is basically arguing that we're likely to see the same state of affairs in VCS land. Sure, there will still be new ones coming into use, and fading out, or finding small niches - but Git will remain dominant for decades to come.
theamk 7y ago
Does not Fossil’s “no rebases” philosophy bother you? IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.
- SQLite 7y ago
  https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
  - theamk 7y ago
    Right - and I think that point 6 and 7 are exactly why I use rebase daily, and why I will never use Fossil. The version control history is made for reading by other people, so it is a story. After all, we only write the commit once, but people will read it many more times. (This is especially true if there are code reviews involved) I am an imperfect programmer. My work-in-progres is often broken, and even fails to compile. Sometimes I will refactor interface only, and will want to checkpoint my work before I go and refactor implementation as well. Sometimes I will choose a totally wrong approach and revert it later. Sometimes I will disable/break large part of system on purpose, to make testing easier. And I often do stupid data-destroying mistakes, so I want an ability to save/store all the past versions, even if they are completely broken. My “raw” commits may look like: “start on feature X”, “refactor interface Y”, “more work on feature X”, “wip commit”, “fix tests”, “fix performance”, “fix more tests”. Does any future reader care it took me 3 commits to get the tests right? Do they care that I discovered the need to refactor only while I was halfway in feature X implementation? Do they want to see a repo that won’t even compile? Do they want to hav to cherry-pick dozens of commits to get the tests to pass? I don’t think so. The final version will only have two commits, “refactor” and “feature X”. It would be obvious to everyone which lines of code are associated with which change. Each revision will be buildable, and will pass all tests - so bisect will actually work. (If rebase support is missing, it is possible to “fake” it by having multiple checkouts and manually copying files around. But this is much more error prone and dangerous. I have spent plenty of time with SVN/CVS, manually copying files and applying patches - and I can tell that having this integrated with version control is much more pleasant)

oxfordmale 7y ago

Git can easily be replaced in my company if there was business need for it. For now it does do its job, but there is no reason we wouldn't migrate if there was a better alternative. Right now there isn't one.

rhabarba 7y ago
Which features would make it for you?
- enjo 7y ago
  Perforce is still in use in content heavy industries because Git still struggles with large binaries. Something with git branch semantics that could handle those files would be huge.
  - emodendroket 7y ago
    Isn't that what Git LFS is about?
    - sergiotapia 7y ago
      This is funny, this exact same conversation happens on hn at least once a month. Reply for reply same convo
    - Aeolun 7y ago
      Yeah, but it’s not really out of the box.
  - m463 7y ago
    I actually like perforce. (if you're not constrained by distributed) It does huge well, and I like the one-number changelist.
    - jayd16 7y ago
      I really miss being able to check in chunks instead of full files, and streams are a poor replacement for git branches but it does let you do monorepo. P4V is a buggy mess though.

thenewnewguy 7y ago

I find it ironic that in the same post the author complains about a git monopoly ("Git effectively has a global monopoly on DVCSes") while wishing the same thing for fossil ("Fossil's world domination will not come from...").

lidHanteyk 7y ago
"world domination", specifically, refers to a long-running joke about the corporate-sponsored capitalist competitors to FLOSS. See [0] for an example of the joke being used to title a talk and frame business decisions. [1] contains a history of the phrase in the Linux world. Note that Linux and git share the same original author/designer. [0] http://www.catb.org/~esr/writings/world-domination/world-domination-201.html http://www.catb.org/~esr/writings/world-domination/world-dom... [1] http://xent.com/pipermail/fork/2002-January/008429.html http://xent.com/pipermail/fork/2002-January/008429.html

consultutah 7y ago

SVN seemed irreplaceable not so long ago and CVS before that and RCS before that... When someone comes up with something demonstrably better and gets the right people to start using it, people will switch over.

rhabarba 7y ago
Note how POSIX still has SCCS as the default VCS (and it is still fine for single file commits)...
colechristensen 7y ago
SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
- emodendroket 7y ago
  I mean so is Unix and it's still around all these years. Heck there's nothing especially obvious about a for loop, yet every language has them. Once everyone's accustomed to the weird interface they are just going to demand everything else have the same weird interface they're used to. This is one of the lamentations of the Unix Hater's Handbook.
  - wwright 7y ago
    If you’re talking about a “for (initialize; condition; step) { body }” for loop, most newer languages don’t have them AFAICT. I would say the other kind of for loop, a “for x in y { body }” loop, is very intuitive and obvious to most English speakers. We use idioms like “for each A, do B” all the time.
    - emodendroket 7y ago
      I meant the C-style one and they do appear in most commonly-used languages, though I guess most commonly-used languages are not all that new.

dustingetz 7y ago

The cloud is going to change a lot of stuff, file-system based code might be gone, code-in-database is already halfway here ... opportunity

krasin 7y ago
I agree with the first half of the statement: we indeed do not have a cloud-first version control system. It could bring some real benefits of tight integration with continuous build and other things considered to be essentials nowadays. I don't see files going anywhere. I would like to listen to examples of "code-in-database is already halfway here", if you happen to have them.
- dustingetz 7y ago
  My startup is one http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ Others are https://darklang.com/ https://darklang.com/ and https://www.unisonweb.org/ https://www.unisonweb.org/ and of course scripting google sheets with javascript Low-code is very suddenly going to be a big thing in the next couple years and when it happens there are now 750M more "coders" and those types of people are not interested in git pull --rebase --fucked --whatdidido
  - krasin 7y ago
    Thank you, very interesting pointers!
- wtetzner 7y ago
  Of course, you could probably build some pretty convenient cloud-syncing tech on top of Git without a ton of effort.
agumonkey 7y ago
tree diff over graphql
- dustingetz 7y ago

emodendroket 7y ago

I am happy to use whatever everyone else starts using, provided it works at least as well. But I also do not have many problems that git won't solve, so I don't feel a burning need to switch. I think git is good enough that source control is no longer a very interesting problem.

ken 7y ago
But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
- emodendroket 7y ago
  When I started developing the options people were taking seriously were Mercurial and git. At first I was using mercurial, but since everyone else was using git I switched to that. So those are the only ones I've seriously used.
- EdSchouten 7y ago
  I don't think there are many people that considered CVS good enough, even back in the days. For example, there was no way for end-users to retain the history of a file when renaming/copying it. When the FreeBSD project still used CVS, committers always had to file tickets against the admins to ask them to do it server-side through a so-called 'repocopy': https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080
- jerf 7y ago
  Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all. There were several times there were builds that were completely unreproducible because it turned out that they were, technically, r83726, except this directory was r84713, but this other directory was r78372 except for a subdirectory that was r84299, etc. That problem I saw even before I saw a replacement. But once I saw git, having a full copy of the repo was pretty killer. It was also better at merging, partially for having the history local. In fact I recall some SVN people protesting at the time that merging wasn't so hard, but in a nutshell, they were just wrong. It was harder. Source control that can't merge fluidly is pretty limited from the get-go. There's literally entire dimensions of things we do with git that were so impractical with SVN that only the very largest projects could afford to do them, with the whole "workflow" question. Now you don't even hear about the difficulties of merging since all the open source SCMs copied each other and "good merging" is just table stakes now. The problem is is that git doesn't really have fatal flaws, it has annoyances, and that's not the same thing. "The UI is difficult" is an annoyance for its target audience. Most every other criticism I've seen of it is an annoyance, not a fatal flaw. Fossil doesn't solve a problem I have with git. It has some neat ideas and arguably does solve some problems, but it doesn't solve the problems I have with git; you could lift Fossil's solutions to wiki and bugtracking and just put them in Git and I'd probably be happier with that than Fossil itself. The problem isn't that Fossil is an SCM competing with git; the problem is that Fossil is a monolith competing with the rapidly-moving git ecosystem. The former is perhaps beatable, the latter is a juggernaut. All of Fossil's other features sitting in git is something that might get somewhere, but if the base source control isn't git-based, I can't sneak it into a work project to try it out. I've got a corporate mandate that all source belongs somewhere standard, and it's a perfectly sensible requirement for someone paying me to do a job.

ken 7y ago

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

dickjocke 7y ago
Can you explain more about that? I've worked with both and I feel like monorepo is kinda a pain, but I dont understand where Git fits in to either directly. Seems like it just snapshots files.
- Skunkleton 7y ago
  In this context "monorepo" means a huge repository with many many revisions. Git has several well documented deficiencies in this scenario. See [1] for microsoft's experiences with git. [1] https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
- chubbyrabbit 7y ago
  It's only a problem at a really large scale. At the scale of Microsoft or Facebook, there are factors that lead to the use of a monorepo being more efficient. At that big of a scale, companies have enough resource to develop internal tooling to deal with the problem (e.g. the use of Mercurial at Facebook).
  - gatekeeperthrow 7y ago
    It would be nice if you and everyone else stopped gatekeeping this problem. We have 600 devs and face these problems. I can assure you we sure as hell dont have the resources spare to reroll git. We're way too busy rerolling everything else.
  - int_19h 7y ago
    FWIW, in case of Microsoft at least, it's more a question of product size than company size. Microsoft doesn't use a single monorepo for everything, like Google (so far as I know) does - just look at http://github.com/microsoft/; http://github.com/microsoft/; and that's not even counting all the VSO repos! It uses product-specific monorepos for some large products.

l0b0 7y ago

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the current contenders. Git made it possible to run VCS without a separate server program and sped up VCS operations massively. Both of those were huge. Looking at the Fossil home page[1] it does have some features I personally have wanted in VCSes, such as integrated "bug tracking, wiki, forum, and technotes," but the devil is very much in the details of how that actually works (How easy is it to write your own custom frontend or add business-critical bug tracking fields, for example?), and it's not like we don't already have good bug trackers, wikis etc. Just as a tangent, some issues (but not necessarily major or fundamental, depending on who you ask) with Git as it works right now: - Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. - Git Annex is not yet built in. - The command line is complex, including many niche subcommands and tons of rarely used options. - The command line is inconsistent, such as `git rm` vs `git branch --delete` vs `git remote remove`. - It is based on a less than ideal theoretical model of patches[2]. IMO this is the most exciting development in VCSes since Git. [1] https://fossil-scm.org/ https://fossil-scm.org/ [2] https://pijul.org/model/ https://pijul.org/model/

rhabarba 7y ago
> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.
- wtetzner 7y ago
  How so?
  - rhabarba 7y ago
    Less overhead, a better UI.

JohnFen 7y ago

Of course Git is replaceable. When a new tool that provides a substantial benefit over using Git comes around, it will be replaced. If that never happens, then it's a pretty strong indication that Git is working perfectly fine -- so why worry about whether or not you can replace it?

zestyping 7y ago

It feels that way, and it's heartbreaking that our entire species ended up locked into a tool with such a horrible interface. In a way, the git monopoly is worse than Windows or x86 or IPv4, because it's not just a piece of technical infrastructure. Its arcane commands and its branching model have infected all of our brains. You can choose a different editor, you can choose a different operating system, but for as long as we all live, we will never escape the fact that "git reset" does a half a dozen confusingly different operations, or that renaming cannot be tracked, or that most users don't fully understand most of the commands they regularly use.

Skunkleton 7y ago
Check out new versions of git. The overloaded checkout and reset commands are being phased out to some extent.

pbiggar 7y ago

I'm working on a git replacement, in a way. The thing that makes git powerful is that its just text. Git is probably the most powerful thing for code as text. When code no longer is just text (and by "text" I mean bytes on disk, not that we're switching to coding with emoji or VR) you get to do more powerful stuff. Our plan in Dark (https://darklang.com https://darklang.com) is to combine all the different ways that people "branch" (deployment, feature flags, git branches, staging/dev/prod environments) into a single concept. And then we also plan to combine all the ways to "comment" (PRs, slack messages, commit message, code comments) into a single concept. Not sure if you'd call that a git replacement, but it's a displacement of sorts - the function of git is replaced by non-git.

zestyping 7y ago
Sounds intriguing! Can you say more about what that single concept is and how it works?
- pbiggar 7y ago
  To be clear, it's two concepts, one for branches and one for comments. The first concept we've been calling deployless, and discussed it here: https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671 https://medium.com/darklang/how-dark-deploys-code-in-50ms-77... The second one is just an idea right now, suggestions welcome. The observation is that comments on a particular line of code are spread in as many as a dozen places (a google doc, slack, trello, the code itself, an old version of the same code, PRs on github, comments on commits on github, commit messages, another place in the codebase referencing this one, the docs folder in your repo, another repo that uses this API, your 3rdparty docs on README.io, etc). This is weird and bad, and it must be possible to do better.
  - shalabhc 7y ago
    For comments, fully agree that we don't need several isolated systems (source files, docs, commit messages, ...) How about one system which is a hypermedia system and can hold many different kind of objects. So annotation objects can reference 'code objects' such as types, fields, functions or even blocks directly. Not sure if Dark gives each of these an identity (it should) which will make it possible to refer to them via hard links rather than text snippets. Once you have all code and comment objects in one hypermedia system, creating views from that is about multiple projections of the interconnected objects. Wouldn't it be great if I can use a query to refer to 'all functions that reference this type' inside some docs? Or list all annotations that reference a function? These could be embedded inside annotations as well. Gtoolkit does something similar. Perhaps even a 'branch' can be thought of as a subset of the hypermedia graph. E.g. using a code block X2 instead of a code block X1 within the same function.

DecoPerson 7y ago

> 1. Metcalfe's original Ethernet has been replaced a bunch of times... These replacements were seemless to users. New Ethernet adapters were compatible with at least the previous spec. The Git import/export of Fossil is not seemless at all. It actually adds quite a bit of complexity if you want to introduce it your regular workflow. > 2. Microsoft's long-term stalwarts Windows and Office are dying... Citation needed. > 3. Adobe's having a hard time hanging onto its old market... Citation needed. > 4. IPv4 still won't go away... There is a lot of hardware out there that only works with IPv4. The costs and risks of switching your org's internals, product or services from IPv4 to IPv6 are phenomenally higher than switching your org from Git to Fossil or adding Fossil support to your product or service. If Fossil is truly superior to Git and people are not switching to it, then there's no hope they'll switch to IPv6. Not until the cost of not switching is greater.

chx 7y ago
> These replacements were seemless to users. Not at all. I remember how long it took for Cat 5 to replace thinnet.
fulafel 7y ago
Wifi mostly replaced ethernet for user facing applications. There was partial protocol compatibility between ethernet and wifi, but the user experience was very different. Some features were lost or degraded (eg speed, reliability, security, configuration complexity) but a pain point (cables) was fixed.

rurp 7y ago

I really doubt Git is going anywhere for the foreseeable future, but I could imagine a more approachable VCS catching on. Git is extremely opaque to most new developers and even for experienced devs looking up a new command. Sometimes I look up how to perform an unfamiliar task with Git and find 4-5 competing answers on Stackoverflow with no real clear explanation of why one is better than another. If an easier VCS caught on enough to be used in schools and boot camps, many younger devs would start with that one and just keep using it as they progress in their career. The new VCS wouldn't have to be better or more powerful, just easier to use for the basic stuff that makes up 95% of Git usage, in order to gain traction. That said, Git works perfectly fine and is so entrenched that I don't see it going anywhere.

roca 7y ago
Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there was a better one. I don't think there is.
- HALtheWise 7y ago
  The obvious pool of people who don't currently use VCS's is everybody who mostly deals with files that aren't plain text. Using git to collaborate on Photoshop documents, Word docs, Jupyter notebooks, videos, or any other non-plain-text format is a frustrating nightmare, and a VCS solution that provided revision tracking and collaboration for all those filetypes would open up a new set of users.
  - james_s_tayler 7y ago
    Just use SharePoint.
- spderosso 7y ago
  However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS I think this is true if you think the target market for VCSs is professional software developers only. But there are other people writing code that might care less about the fact that Git is the standard for professional software development and don't want to pay the cost of learning or using Git: data scientists, scientists in general, new media artists, most high school students, etc. I've had a hard time selling Gitless (https://gitless.com https://gitless.com) to undergrad CS students, but it is easy to sell to non-CS students that write code. That said, GitHub is a big thing so any new VCS probably needs some story for Git-compatibility. Even tools that have built-in version control like Overleaf have some way of synchronizing with Git repos.

comex 7y ago

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) leaky abstraction. Microsoft's GVFS is a promising attempt to truly scale Git to giant repos, but it's developed as an addon rather than a core part of Git, and so far it only works on Windows (with macOS support in development). GVFS arguably has the potential to become an ubiquitous part of the Git experience, someday... but it probably won't. Git also has trouble with large files. The situation is better these days, as most people have seemingly standardized on git-lfs (over its older competitor git-annex), and it works pretty well. Nevertheless, it feels like a hack that "large" files have to be managed using a completely different system from normal files, one which (again) is not a core part of Git. There exist version control systems that do scale well to large repos and large files, but all the ones I've heard of have other disadvantages compared to Git. For example, they're not decentralized, or they're not as lightning-fast as Git is in smaller repos, or they're harder to use. That's why I think there's room for a future competitor! (Fossil is not that competitor. From what I've heard, it neither scales well nor matches Git in performance for small repos, unfortunately.)

james_s_tayler 7y ago
I'd say the number of git repos on Earth that would encounter problems of that nature would be a vanishingly microscopic minority. Sure, it's a problem for those companies but it's not a problem for anyone else.
- hamandcheese 7y ago
  Vanishingly small in number, but quite significant in terms of the number of developers working in them.
  - Polylactic_acid 7y ago
    All of the organizations that have outgrown git will have such incredibly specific requirements meaning nothing but a custom built tool will work for them.

romwell 7y ago

When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify the code before the commit gets checked in. The history of the comments and changes should be maintained. There is nothing in Git that supports this flow in a natural way. A replacement for (or evolution of) Git can be a tool that would support this code review flow from the get-go. And yes, there are external tools for code review. But that all should be a part of version control.

tick_tock_tick 7y ago
I think it doesn't exist because there is no demand for that to be part of the codes history. Nothing you've described sounds very useful after a month or so.
- romwell 7y ago
  Sure, but keeping that history is just a small part of what I said. The point about code review still stands.
  - rhabarba 7y ago
    That's the one major point where Fossil probably falls short: Extending a repository's capabilities would add overhead to every single one of them (and, potentially, to each commit's meta data).
- pbh101 7y ago
  All this talk of Git-sympathetic code review tools and nobody has mentioned Gerrit, which seems at least somewhat close to what is being described. Each patchset of each review is its own Git ref and is often referenced in the final commit. Separately, I know many including myself who would love for code review comments to more seamlessly be integrated into the code browsing experience.

vfclists 7y ago

When they say Git, isn't Github and Gitlab they actually mean?

sys_64738 7y ago

Git is a tool to get the jobs done, not a religion.

kjgkjhfkjf 7y ago

Eventually git will be replaced by something better. It might not be replaced everywhere, but eventually it will be replaced in most places. This is true of almost all things in tech. I expect that git's eventual replacement will initially boast compatibility with existing git repos.

pg_is_a_butt 7y ago
Anything that could maintain compatibility with git repos after an initial import process couldn't possibly be any better than git.

taspeotis 7y ago

If you take a look at Subversion vs. Git's interest on Google [1] and you agree it has some correspondence to the technology adoption lifecycle [2] ... Git's got a long way to go. [1] https://trends.google.com/trends/explore?date=all&q=%2Fm%2F012ct9,%2Fm%2F05vqwg https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... [2] https://en.wikipedia.org/wiki/Technology_adoption_life_cycle https://en.wikipedia.org/wiki/Technology_adoption_life_cycle

734129837261 7y ago

I wish there was a version control system that didn't need user input beyond a "push". Only branches and pull requests, nothing more. No commit messages, you have one master branch and however many sub-branches you need. Whatever code is in your branch is what it is. And then there's a layer of magic on top of it all, maybe a UI or command line tool or both, just to be able to easily rewind time. Either per file, per line of code, or folder, or just a folder but not recursive, or the entire branch. Think of Apple's Time Machine, it should be that simple. Honestly, I rarely–if ever–read commit messages to begin with. The way I navigate older code is never done by searching for commit messages. That's not reliable. Instead I simply go to a point in time where I think the thing I'm looking for might be. I'll look at the code, recognise its state, and continue the search up or down the timeline. And that would cover the needs of most projects I'd say. And it would save us a shitload of time. Hell, I've been working with git for almost a decade now. I never needed to rebase or merge things, until I recently did need to do it. It's too arcane to make intuitive sense, to me anyway. Git is good, I'd just welcome a breath of fresh air...

tenken 7y ago
Do you work on a team? Or in a job were you need to have an audit trail for your work? Commit messaged and many other features of Git like branching and tags are indespensible for sharing and collaborating on code.
- eesmith 7y ago
  Flip your questions around. Might someone who isn't on a team, and doesn't need an audit trail, want something simpler? Versioned files systems, including Apple's Time Machine and Dropbox's version history, have no extra UI to save versions. A small, short-lived project with at most a few collaborators (eg, working on a small scientific paper) might find those more useful than git or other VCS.
  - at_a_remove 7y ago
    I would have to agree with this. I have been programming for decades and I haven't had to work on a team for a project. "Branches" have not happened, nor have I ever felt the lack of them. I would not mind something simple. I find the arguments, flags, whatever in git to be rather opaque. That, coupled with the lack of need for its features, have not thrilled me. It seems to be pretty effective if you have tons of programmers working on a single project, but at the bottom end of the scale, I find it baffling.

harry8 7y ago

Taking the question literally, obviously not. If git became a problem due to some unforseen licensing issue or whatever mercurial does the job just fine right now and has for years. As a heads up if you're stuck on cvs, svn or other stupid vcs due to "old-codgers" in your office, mercurial has a shallower learing curve and easier ui to get the same job done which may make it easier to switch. Either git or mercurial, who cares? Either of them until there's something better. Never deal with SVN & CVS branches and merges again. Feel the immediate team productivity boost which will pay for the initial learning curve costs by day 2. Seriously.

choeger 7y ago
> day 2 Unfortunately, you have to settle on some workflow for that. And this settling will take some experience and discussion. So "day 2" sounds very overambitious to me.
- harry8 7y ago
  Use the existing svn/cvs workflow with the trivial changes for git/mercurial. Central repo, push when you're done to master. Branches are all but unusable on cvs/svn anyway - if you do use them, feel the win and laugh with glee. When everyone is on top of that basic workflo then you do something incrementally better. Really it's day 2, really. I've seen this more than once now. The fight to get to that point where the changeover happens is getting easier but I'm sure it still sucks.

HALtheWise 7y ago

One major fundamental issue with git that nobody has brought up is that its data model is close-to-incompatible with some of the current legal and moral requirements around data privacy today. For example, as far as I can tell, GDPR allows any European citizen who has ever committed to the Linux kernel to request that their name be permanently expunged from their contributions, and everyone with a git clone of the kernel is legally obligated to perform a rebase to do so. It's possible to make a DVCS where that is an easy operation, but git very much isn't it. That means it can't be used to store personal data, and even standard corporate policies of "we delete old historical records so they don't bite us in court" aren't supported. There are definitely times you want to store the full history forever, but it would be nice to have a DVCS that gave other options.

0xff00ffee 7y ago
Like when I accidentally check in credentials. /insert Michael Cain playing Homer sound: Buh-oh./
GauntletWizard 7y ago
The legal requirements in the EU are at odds with the moral requirement. Changing or erasing history in Git is an anti-feature. Checked in secrets should be assumed to be compromised and changed immediately. Removing contributions should be treated as any other form of censorship. Those who forget (or rebase away) history are doomed to repeat it.
fsh 7y ago
Could you cite the paragraph of the GDPR that requires this?

kseo3l 7y ago

git has big problem with binary files, hopefully a new technology can fix that

ChuckMcM 7y ago

Does Fossil do sub-modules correctly? Specifically does it let you compose a project of several repositories and do configuration management on that repository? That is something git kinda sorta does but it gets out of control easily.

hinkley 7y ago
I like the idea of storing commit history in a database. Why write all of the bits from scratch? But I don’t like how difficult databases make it to represent graphs of data. To pull a subtree cheaply, you need a graph. not unlike SVN’s data structure.
- swish_bob 7y ago
  Use a graph database?
jldugger 7y ago
Is this something you want in a VCS, or can it be adaquately handled by something like myrepos?
- ChuckMcM 7y ago
  It is something that I prefer to have in a VCS. At one end of the spectrum you treat a repository as a object which a containing repository can subclass with specific changes. Such a system would allow things like basic driver frameworks for a bunch of devices to be in their own repository and the 'critical bits' that make them work in a system of type 'x' would end up being a that repository + changes. You can kind of do this with git where you create a branch for each system x, y, and z in the repository and then your submodule is driver repo branch x but that doesn't put the maintenance burden in the right place (the system X maintainer).
rbehrends 7y ago
Fossil's intended use case is different from Git's; it was originally built as the VCS for SQLite. In terms of its target audience, it's basically GitHub-in-a-box for small or medium-sized teams. Implementation/usability-wise, it does some things better than Git, does other things worse, and yet others simply different (in a way that some may find better, some may find worse).

interfixus 7y ago

For what it's worth, the linked page is itself running on Fossil, which has of course build in forum facilities and several other suchlike goodies - being a complete solution, packed into a single smallish executable with no significant dependencies apart from SQLite. The Fossil site runs on very moderate hardware, and gets no hiccups from hitting the HN frontpage. I like this kind of untroubled minimalism, and so far have never encountered a reason not to run every personal project on Fossil. The real world will occasionally force me onto Git territory, but I can't really say I have ever enjoyed the experience. Git is here to stay for any foreseeable future, of course. And while I do understand points often made about the benefit of one de facto standard to rule them all, monolithic dominance always tends to unsettle me. My SE friends in general simply use 'Git' as a given synonym for 'version control'. And it does annoy and somewhat worry me that they've never even heard of Fossil until I roll out my sermon.

petre 7y ago
We use Fossil as well @work and we love it, although I don't think it's not the best choice for huge codebases such as the FreeBSD ports tree which I tried to import once to see how it scales and gave up after >2Gb and a hour or crunching. Maybe importing into nested repositories would work better?

tasuki 7y ago

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

brylie 7y ago
The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.
- kortilla 7y ago
  The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.
  - afiori 7y ago
    Yet no one is doing it.
  - baud147258 7y ago
    > There is nothing preventing you from writing a different front end Or you could just use a tool where the interface is fine out of the box
  - wyoung2 7y ago
    Which is why there are dozens of Git front-ends, fragmenting the market, reducing the benefit of cross-training within a team. "Oh, you can't do that in your TortoiseStudioCodeThingy? I just right-click and select Frobnicate File, and it fixes all that!" Thus editor wars, language wars... Alternative: a tool like Fossil where the CLI is sensible from jump so the whole team doesn't replace it with something better, uniquely per team member.
matsemann 7y ago

mikl 7y ago

It’s not irreplacable. But it’s very well put together, and a great ecosystem of tooling exists around it. So any potential replacement would have to be a lot better for people to move. And for those of us that remember the dark days of CVS and the pain of migration (I helped migrate drupal.org from CVS to Git), that is a good thing. I don’t miss the days where you had to make difficult SCM choices when starting a new project, whether bzr, Mercural or Git was the right choice. Git has become the lingua franca of SCM, and that is great. So many great developer tools exist that integrate seamlessly because it is safe to assume that 99% of the audience for it will be using Git.

tomesch1982 7y ago

The git internals are good for some kinds of projects but for the actual majority of projects git is a very bad fit. Most people don't get that because they are blind for the much better tools like mercurial and fossil. The git UI/UX on the other hand is the worst piece of crap ware known to man. This piece of shit has probably destroyed more data than any other tool ever written. People who think that git is any good are obviously wrong and can easily proven wrong. It's sad that git has become the default.

rimliu 7y ago
How funny, it was actually mercurial that destroyed my repo. Never looked at it again. Also, it is very hard to "destroy data" in git.
quleap 7y ago
mod this up

throwGuardian 7y ago

> Microsoft's long-term stalwarts Windows and Office are dying Judged on what metric? Office's paying monthly active users and revenues have consistently grown, measured both quarter on quarter, and year on year

majewsky 7y ago
I would probably think the same if I were stuck in my Linux bubble, but $WORK allows me to observe the average computer worker. They're incredibly deep in the Microsoft ecosystem and not at all interested in switching.

jasoneckert 7y ago

Am I the only one who read this thinking "Oh come on....git with the program dude...."?!? Seriously, I love git.

mikece 7y ago

The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to Show HN your ability to implement the same thing in Rust with lower memory and better safety? Awesome! But with Git this isn't possible because there's no concept of the API or interface for distributed version control being separate from the implementation -- and the discussion of "could the API be better than what it is now?" has never been had in a meaningful way.

crazypython 7y ago
Isn't its API the file system layout? I use GitUp, which interacts directly with the .git/ folder.
orf 7y ago
There is, it's the .git directory. Both the protocol and the directory are well specified. See libgit2 for an example non-reference implementation. I think someone even built an implementation in bash, but I can't seem to find it now.
- Iwan-Zotow 7y ago
  > I think someone even built an implementation in bash, but I can't seem to find it now. someone named Linus, I guess?
  - orf 7y ago
    No, it was someone exploring git internals by writing a simple git implementation in bash.
augusto-moura 7y ago
Of course it has, the other implementation that comes to mind now is JGit [1], a git implementation in Java. A lot of IDEs, build plugins are using it for interfacing with git without the mess that is JNI [1]: https://www.eclipse.org/jgit/ https://www.eclipse.org/jgit/

quadrifoliate 7y ago

I find it amusing that the author mentions Git and Excel in the same breath. One is a GPLv2 piece of software that you can submit patches to, fork, or build your own copy and sell it (so long as you release the source); while the other is a closed-source piece of software that provides largely static utility to many people, yet keeps increasing in price (latest is ~$100/year for an "Office 365" subscription if I remember correctly). Imagine if you had to pay $100/year to use Git. I would probably hand it over, begrudgingly. But the fact that I don't is probably one of the more important triumphs of Free Software over proprietary in recent years.

tzury 7y ago

Bazaar and Mercurial are dying... Bazaar is dead, and Mercurial is near death. Linus wrote the Linux kernel and it became the "de-facto standard" for web application stack servers (and phones, and watches, and Chroemcast and all sort of `Internet things`) Linus wrote git and it became the "de-facto standard" for version control. If a world had 23 more Linuses, we would have full control over our SaaS and "Clouds" and not locked-in as we are at the moment. But we have only one like him.

alexhutcheson 7y ago
Facebook[1] and Google[2] have both publicly stated that they are using Mercurial internally, so "near death" seems like an exaggeration. Mercurial has some significant advantages over Git if you want to implement a scalable backend for really large repos. [1] https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... [2] https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
- BjorksEgo 7y ago
  Theres been plenty of work done to make git enterprise scale in the last year https://vfsforgit.org/ https://vfsforgit.org/
  - alexhutcheson 7y ago
    That's a promising project, but it's currently Windows-only. My main point was that Mercurial is very much "not dead yet!"
bytematic 7y ago
It's likely that there are many Linus's but they are not in positions (third-world, poverty, poor parenting, dictatorships) to achieve the same. That's why I think the biggest progress in tech/innovation will come with lifting as many people as possible out of those situations

micimize 7y ago

fossil is a really interesting project, but the switching cost from git is pretty massive. The two killer issues for me: * community/history: any issue I have with git, someone else probably has had. Being a pioneer is very expensive, time wise. * ecosystem/tooling: aside from git host provided tooling, there're integrations for vscode, slack, CI, etc.

lasereyes136 7y ago

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... - Any headline that ends in a question mark can be answered by the word no.

omarhaneef 7y ago
Do you mind if I take all your money?

hnrodey 7y ago

Unsure if this is just my hot take but... GitHub is what mainstreamed Git to what it is today. Who knows what our industry would look like (with regards to source control) if GitHub never existed. Probably still SVN and Team Foundation Server (shutter).

pixelbath 7y ago

Absolutely not. Give me something that can more elegantly handle sub-projects and sub-repositories but still works as well as Git, and I'll stop using Git today.