14 ms·

What comes after Git?

70 points by mariuz 6y ago

seanalltogether 6y ago
Git submodules just don't seem to work in practice, and that could be a big chance for a competing scm to overtake git. Having dependency management inline with scm would allow for more simplicity in the overall process.
- amelius 6y ago
  This is also my biggest issue with Git. And integrated/streamlined support for large files.
  - wickedOne 6y ago
    what would be a typical large file you want to have in your codebase? usually this shouldn't be a consideration
    - _ph_ 6y ago
      I recently had to deal with a PowerPoint document which is slightly larger than 50 megabytes, which in todays terms, isn't very much. Before, I had kept it in SVN and that has no issues storing larger files. It is a bit shocking that Git has issues with not so tiny files.
    - diffeomorphism 6y ago
      I want to use it for files not just source code. For instance including graphics, the pdfs generated by latex or just anything. Or storing lots of directories. Currently, I use dropbox for that, but if git could do that...
      - wickedOne 6y ago
        though i agree that there isn't a proper vcs out there for large files (adobe bridge was a nice attempt) git wasn't designed for that and one might wonder whether you want git to be _that_ multi purpose.
        _ph_ 6y ago
        If you have a significant project, you want to store at least a reasonable amount of media with it. Images, documentation. Git doesn't necessarily have to be the best system for handling high-gigabyte sized binaries, but should at least deal gracefully, with small and medium sized binary files. I am also not sure, why not more effort was spent making Git support large files even well.
        amelius 6y ago
        By the way, if you're storing large files under version control in Git it is often useful to use the "--depth=1" flag when cloning or pulling repositories. That way you only download the stuff you really need and leave the rest of the history on the server until you need it.
      - sofixa 6y ago
        Git LFS can do that.
        war1025 6y ago
        Git LFS is basically the CVS of binary file version control. It is a pile of garbage, but it's better than nothing.
    - amelius 6y ago
      In addition to what others posted here, sometimes it is nice to put generated files under version control with the source code that generated them. For example, simulation results, deep learning models, graphs that you need to include in your LaTeX documents (which can be considered partly source code, partly generated content). Also, deep learning training data often consists of large image files, and can also be considered "source code", and in any case it can be very useful to put these under version control. And finally it can be useful to put external dependencies as tar-files into your source tree.
      - watwatinthewat 6y ago
        I appreciate you laying this out because it's something I have struggled with and thought I just didn't know the right way to handle it. For writing tests in a deep learning code base, rather than simply including a native data file (image, CSV, whatever), I've taken to writing a fake data creator class. It always feels like overkill when an alternative solution is including a native data file or two that already exists.
    - xiphias2 6y ago
      It doesn't matter actually. Tools should be easy to learn and as free of edge cases as possible. An example happening is constant propagation in Rust: it's the same feature, but with every release it can cover more of the code base.
  - sofixa 6y ago
    Git LFS has been a thing for years.
    - amelius 6y ago
      Git LFS is not integrated well enough, imho. As I posted elsewhere, this software uses a separate network channel for transferring large files. You can't use it with git-daemon and git-shell, but you'll have to setup another server, configure access control etc. and your repository will be split into different parts of your file system.
    - deleted 6y ago
      [deleted]
    - aesh2Xa1 6y ago
      Git LFS lacks a "host your own server" setup. That's a big downside. Hosting your own revision history should be simple.
      - overgard 6y ago
        I'm doing that with LFS on a gitlab droplet on digital ocean and its trivial (with like a hundred gb repo). Dunno if it was bad in the past but it's not hard now.
    - war1025 6y ago
      If you want a terrible time, have several members of your team not install git lfs, and have them be the main people that commit binary files. LFS uses some sort of internal filtering and tracking to determine which binary files might have changed. It seems to have trouble deciding if there are actually dirty files that need changed. So you can't just say, "Okay, go find all the binary files that didn't actually get moved to LFS and correct them" Instead you end up with random moments where you want to commit a single file and git instead detects 1000 png files that it absolutely could not go on without doing something about. But then the diff is a disaster so good luck understanding that what it is actually mad about is that it wants to move the files into LFS. The only way I finally figured it out was to manually load the object blob and notice one of them was an LFS pointer file. I personally think git annex handles things more elegantly, but lfs won that battle.
  - vadishev 6y ago
    This and also path based access (limiting access to certain directories/files within a branch).
- wickedOne 6y ago
  been using submodules for years without any issues other than the routine before "deinit" was introduced was somewhat tricky. could you elaborate?
  - rwmj 6y ago
    I've been using git submodules for years but there are some real problems with them: * Changing from a subdirectory to a submodule breaks lots of things like git reset and git bisect. * Having to remember to git module init, update etc. I always have to look up the commands and never remember what the difference is. * I don't care that there are unlisted files in a submodule, either don't bug me about this in status, or integrate commands in such a way that they work transparently across the main module and submodule. * Related to the previous: Coordinating a single logical change across submodules involves several manual steps and has plenty of scope to go wrong.
- junon 6y ago
  Submodules are stupid easy, what issues do you have with them?
  - ducktective 6y ago
    Once I accidentally added a sub-module to a repo. Had to jump through all kinds of hoops to fix that. - An edit in .gitmodules - An edit in .git/config - A removal in .git/modules (seriously?) https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule https://stackoverflow.com/questions/1260748/how-do-i-remove-... https://gist.github.com/myusuf3/7f645819ded92bda6677 https://gist.github.com/myusuf3/7f645819ded92bda6677
    - junon 6y ago
      Deinit didn't work? And that's the only issue you had with them?
- vadishev 6y ago
  To be honest, I doubt better submodules are gonna help you overtake Git, there's too much inertia in this market. Take for example Mercurial which is a great tool and exists forever, yet it still lost its battle to Git. I'd rather believe that submodules are fixed at some point or an alternative solution appears that works much better. Git subtree is around for a while and there's also Git X-Modules https://gitmodules.com https://gitmodules.com which is modules on the Git server.
aspyct 6y ago
Git still works great. Why would it need to be replaced, just because it's 15 years old? I can think of a zillion things that are over 15 years and still very much working.
- usr1106 6y ago
  The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.
  - hprotagonist 6y ago
    magit is grand. but editor specific.
    - kubanczyk 6y ago
      I often just magit on a separate terminal and edit with some other IDE/editor. You don't need to learn emacs beyond C-X 0 and C-X C-B really. Productivity is higher than with manual git commands.
    - dotancohen 6y ago
      That's like saying that the Git CLI is specific to CLI users. It is, but anybody can use the CLI or open Emacs no matter what they use to edit the code. I personally started using Emacs for Org-mode, but I code in the Jetbrains IDEs. Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.
  - masklinn 6y ago
    > The porcelain would deserve a more consistent and easier to use implementation. Many have taken a crack at it over the years, from very early on. Issue's no porcelain will even replace the built-in one (and what improvements are added to the standard are generally flawed to hell, just look at how messy the brand new `git switch` already is, the git core team simply has no taste when it comes to CLI), and as the creator of a new high-level CLI by the time you'll have good enough feature coverage for it to be useful you'll know the plumbing so well the porcelain will make perfect sense. So you'll abandon the project as offering little value for the maintenance cost. And a few years later somebody else will come in and create their own, and repeat the cycle.
uvesten 6y ago
I’d contend that we might have another 15 years to go before the general developer population have gotten so used to git that they are actually using it in an optimal way for their purpose. Then we’ll find out what its real pain points are, and start working on something new to solve those.
- rwmj 6y ago
  What features should we be using in git that typical developers don't use? I would guess some kind of answer involving complex branching schemes and/or "octopus merges", but I consider myself a fairly advanced git user and find those too hard to understand. I always stick to simple linear histories with occasional stable branches.
  - kubanczyk 6y ago
    Git blame and git log per-file. The commit messages could be the ultimate historical record of all the decisions and the "why"s. Yet, on most projects, saying "I went to read the git log and found out the reason of x" instantly elevates you to a superhero status.
    - rwmj 6y ago
      I guess we mix in different circles because all the developers here use git annotate and git log file|dir regularly. github even has buttons for both operations so you don't need to use the command line.
    - war1025 6y ago
      I would say that this command is much more useful than git blame: git log -p --follow <file>
  - moogly 6y ago
    IMO, rebase. I get so depressed everytime I see a merge commit, not to mention when a bisect ends up pointing to one. But it's very difficult to convince some developers it's a smoother workflow.
tails4e 6y ago
The file size limit of git is a bit annoying. I've moved to svn for a few projects that required large binaries to be shared and version controlled along with their source (for hardware design projects) and hit the 100Mbyte (IIRC) file limit. Im sure it could be fixed, but it is a limitation that has prevented me from using git in some cases
- profunctor 6y ago
  Git lfs is what you want.
  - amelius 6y ago
    The problem with this software is that it uses a different channel to transfer the large binaries. If you're using git-shell or git-daemon to host your git repositories on a server, then you can't use that alone to also manage transfer/access of stuff that is managed through git lfs.
  - andromeduck 6y ago
    Broken on Windows.
  - _ph_ 6y ago
    Why isn't is integrated into Git out of the box? Why do I as a user have to be aware of a separate large file support? Why do I have to install and use a separate tool for this?
  - emerged 6y ago
    Everyone immediately says that when this topic comes up, but afaik it doesn’t even transfer or store files as deltas. Each time you change 2 bytes in a multiple GB file, you get to transfer and store an entire duplicate. IMO that is not a genuine solution to large files.
    - NineStarPoint 6y ago
      In fairness, that’s because gitlfs’s primary purpose is to store binaries where changes in the representation don’t actually map to anything useful. There definitely is a separate use case out there for storing large files where only deliberate changes are made to the objects.
ksec 6y ago
Hg (or Perforce)? But Git / BTRFS are Linux, Where Hg / ZFS are BSD. Something better could always come along, whether it gets significant adoption has very little to do with its technical capability.
- masklinn 6y ago
  > Hg (or Perforce)? They were there at the same time (or before) git, and they don't provide significantly more value than they did then. While I do think they provide value beyond what git offers (my kingdom for revsets instead of the hell that is gitrevisions(7)!) the "market" rejected them then, it has little reason to switch now.
- robert_foss 6y ago
  Hg/Mercurial & Perforce both existed when Git was created, in fact perforce is part of why Git was created.
  - masklinn 6y ago
    > perforce is part of why Git was created. In what way?
    - robert_foss 6y ago
      Ah sheeit. I misremembered. The linux kernel used to use bitkeeper not perforce.
  - Zash 6y ago
    Mercurial and Git were both created around the same time in response to the same need for the Linux kernel to find a new vcs.
smaslennikov 6y ago
I'm surprised Phabricator hasn't been mentioned. I haven't used it much, but it's rather huge in some circles.
- junon 6y ago
  Phabricator and git are almost oranges and apples.
andromeduck 6y ago
IMO what the open source community really needed is a google3 like CI system if only to give library/ecosystem projects like Gnome a greater appreciation of just how much havoc they've wreaked downstream and a better sense of usage patterns in general. IMO the utter disaster that was gnome3/gtk3 transition is what killed what momentum there was for a mainstream Linux desktop.
rhn_mk1 6y ago
I'm watching Pijul, as it seems it has the potential to solve some merge problems, like using the same commit twice in two parents.
lmarcos 6y ago
I think Git will stay as long as we keep representing and working with code as plain text files. Of course I cannot think of a better way of working with code that is not via plain text files (otherwise I would be already rich) but somehow I doubt that programming in 2120 is going to be like programming today: manipulation of code as plain text (although we have to admit that programming has been "manipulation of plain text files" since its very beginnings). Git is still good for tracking changes in plain text files.
- gnufx 6y ago
  I don't think the original stored program computers even had files, but I don't know when the first recognisable filesystem was. There have been a number of image-based systems which you can program directly, possibly by direct manipulation, even if you ultimately store the image as a (binary?) file.
wickedOne 6y ago
don't fix what ain't broken? i think as long as git keeps evolving and there are no major pitfalls for any programming language: why should it be replaced?
- rurban 6y ago
  Because it is broken. Merges and rebases rarely work without manual intervention, a patch-oriented tool that is almost as fast as a snapshot-oriented tool, git. Something like Pijul looks promising.
  - pskinner 6y ago
    It doesn't work because your changes conflict? How would anything else handle out of order modifications to files that cannot be resolved automatically? There will always been a requirement to do this manually - otherwise the VCS would be able to program for you (understand what is right/wrong).
hannofcart 6y ago
I think git is here to stay for a long time. However, I wonder if there's space for a command line git wrapper makes it much harder to shoot yourselves in the foot via scenarios documented at: https://ohshitgit.com/ https://ohshitgit.com/ I imagine this could be achieved by using more intuitive nouns for subcommands (reflog, rebase) and giving informative warning messages on the command line when you are about to screw something up irrevocably. Eventually, one would hope that some of the more effective features of such a wrapper can find their way back to the git project itself.
- wickedOne 6y ago
  git has a steep learning curve for sure, but eventually scenarios described at oshitgit should be common knowledge for anyone using it. personally i think putting out sites like that is more helpfull than dumbing down git
- IgorPartola 6y ago
  git pull rebase should be a top level command for example. Now you don’t get extraneous merge commits if you pull after making a local commit. I have it as an alias for git pull.
  - jasonpeacock 6y ago
    You can make that the default `pull` behavior in your Git config: git config --global pull.rebase true You should also enable `rerere`[0]: git config --global rerere.enabled true [0] https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
  - u801e 6y ago
    Personally, I think that git pull should not be a command that one can run in normal situations. The common expectation when one is making changes, is to commit and then push. So why shouldn't the same apply when getting changes from the remote. That is, fetch and then apply to the local work tree.
    - 6y ago
js8 6y ago
A paradigm shift, perhaps. Possibly, a notion of "changeset" which is more coherent with the actual code changes. For example, Unison language (https://www.unisonweb.org/ https://www.unisonweb.org/) is a good candidate. I would also like to have the following workflow (in functional language like Haskell, in more imperative language it would be trickier): Before I start working on a code change, I mark the functions and types that are to be modified. A tool then calculates a "change boundary", a set of function calls that potentially have a different semantics in the new code. After I am happy with the boundary, I will start working on a replacement code inside the boundary. The old code will still be available alongside to run and inspect during the whole development process. An automatic test suite generator will run the tests on the old code and by observing the boundary, it will automatically create a regression test suite for the replacement code. Once I am done with the new code, and it is tested, I will let the tool replace it in the defined boundary as a new change. So I will have a guarantee (through types) that I am only changing things that have to be changed, nothing else.
timwaagh 6y ago
Perhaps something that knows to deal with assets a bit better. Or maybe that could just be a new version of git. Also diffs could be more language aware. Maybe via a plug in system. Definitely some room for improvement.
- vlovich123 6y ago
  Git-lfs?
rwmj 6y ago
I'd like to see a git-like tool that works on the Abstract Syntax Tree rather than being basically a text tool. Of course such a tool might end up being very specific to a particular programming language, which would be not good.
amboo7 6y ago
Sooner or later, we should stop using textual diff and switch over to higher level one/multiple, such as the AST-level diff (see what GrammaTech does, for example). This and integration of dependency management, is a must IMO.
- vadishev 6y ago
  I think the next SCM tool to Git, is what a Jetbrains IDE is to a text editor. It's an integrated environment on top of Git which deeply understands your code structure, dependencies, etc.
CJefferson 6y ago
I think there is a good space around "version control for everyone else". I have been using overleaf for writing papers, which just does auto sync, and commits to a git repository in the background. It isn't perfect, but it is the best thing I know of for letting experts and beginners work together smoothly.
- jcfields 6y ago
  Mac OS has had a built-in file versioning system (separate from Time Machine) since Lion or so that works with any program that uses the standard document saving APIs. Most Mac users probably aren't aware that their computer stores potentially hundreds of previous versions of their documents (in evictable space, of course). The interface for it is kind of trash and isn't accessible in every app, though. (Over the summer, I made a command-line [https://gitlab.com/jcfields/versions https://gitlab.com/jcfields/versions] and a GUI program [https://gitlab.com/jcfields/restore https://gitlab.com/jcfields/restore] for accessing this system outside of the standard UI, if anyone's interested, though the binaries are not notarized so the OS will show a scary warning the first time you use them.) Granted, it's not exactly the same thing since you're not making commits at discrete and meaningful points like in a software version control system and since it works on an individual file level, which might not be ideal for every workflow, but it's still really useful when you realize you need to roll something back to an earlier state. I think modern versions of Windows use the Volume Shadow Copy service to store backups of files at given snapshot points (such as when your computer runs a scheduled backup or creates a System Restore point), which can be pulled up in the file properties. I use to use NTBackup to do basically the same thing in a more crude way back in the Windows XP days. This isn't as nice as the Mac Versions feature since it requires setting up periodic backups, but it's something. I'd be curious if any of the free desktops have come up with a simple and user-friendly solution to this. I feel like this is an area where there's a lot of room for improvement, since the majority of users would probably benefit from these systems but most aren't even aware they exist.
- bird_monster 6y ago
  I work at a games studio, where artists/designers create and manage game assets via our game's source control. I personally dislike Git, but I absolutely think Git is a borderline-unacceptable choice for everyone that hasn't been hazed into the industry with it. The amount of "I accidentally lost all my animation files for ____ feature" is huge. I think most of the positive talk about git UX just waters down to "I know it already", which is evidenced by most of the responses to valid git UX criticisms being "You just don't understand." To me, version control should be as complex as a user wants it to be. Meaning, UX so obvious that you don't need docs or manuals or youtube videos to do the simplest of tasks if you don't want to. There should definitely be room for power users to be power users, but I think git absolutely fails at letting both novices and those that aren't interested in version-control-as-a-specialty be consistently productive and safe. It's always been very curious to me that, for so many parts of dev, we re-invent the wheel a thousand times to try to find the "right" configuration, which ultimately leaves you with a very wide array of options for every one job, but for source control we seem to have just kind of shrugged and said "Git's fine."
jasoneckert 6y ago
The more I learn about the underlying architecture of git and how it was developed and evolved, the more I see the Unix philosophy at work. As a result, I don't think git will ever be replaced, but merely evolve further according to the needs of developers (and others). In the near future, I think we're likely to see more specialized git frontends and additional collaborative functionality than another version control system.
- GoblinSlayer 6y ago
  Like PHP.
- eesmith 6y ago
  I think the Fossil system, built on SQLite and its powerful query system, is a superior architecture. "Unix philosophy" has always been in the eye of the beholder. I think Perl showed the 1980s Unix philosophy of "small programs, working together", was often overly cumbersome.
overgard 6y ago
Well, what needs to be fixed? The way I see it: - Built in better binary/large file support - Need to be able to checkout subtrees and host monolithic repos (submodules are a pain) - Better UI
UweSchmidt 6y ago
Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. It will likely come as part of an integrated work environment (some collaborative cloud workflow thing) in order to bypass git's role as gatekeeper/rite of passage for developers.
- Slackwise 6y ago
  That's more a case of UI rather than implementation, yeah? What's stopping us from just using those words to describe operations with Git? I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1]. (Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.) [1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455 https://news.ycombinator.com/item?id=25537455) [2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Manager https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...
  - UncleMeat 6y ago
    UX matters. Databases aren’t just data structures and their operations. They do compete based on interaction patterns and metaphors. VC can do the same.
    - Slackwise 6y ago
      I don't know a single database that is identical to another in implementation and just has a different UI/UX for it. Every single database has something specific for it in terms of implementation. (Unless I guess we're talking forks of MySQL.) I don't know if maybe you have a good example...?
      - 6y ago
ghoward 6y ago
Unlike CVS and Subversion, git is big enough that it won't just be replaced. What comes next needs to be incredible to even have a chance. Personally, I think the next big VCS will have the ability to handle all files, including binary ones. (See https://gavinhoward.com/2020/07/decentralizing-the-internet-and-other-ideas/#version-control-for-binary-files https://gavinhoward.com/2020/07/decentralizing-the-internet-... .) As a bonus side effect, this would probably give that VCS the ability to handle source code by semantics.
jeswin 6y ago
I have bet my startup on the future of git, as a decentralised store for personal data. My view is that git hasn’t peaked at all in terms of usage, and currently only serves the developer niche - while its future might be as a store of personal data for the general public. Sort of how computers were niche products compared to now when everyone has one in their pockets.
- GoblinSlayer 6y ago
  Git is distributed, not decentralized.
kumarsw 6y ago
The state-of-the-art for backup is deduplicating software (Borg, Restic, Duplicacy). Gripes about Git's UI choices aside, Git was designed around human-readable text files and just doesn't do large binary files well. Sure, there's Git-LFS, but it sucks. The future of version control will: (1) Make use of deduplication to handle large binary files, (2) Natively supports remotes via cloud storage, (3) Doesn't keep state in the working directory so that projects can live in a Dropbox/OneDrive/iCloud folder without corrupting the repo, (4) is truly cross-platform with minimal POSIX dependencies. I've been playing around with a proof-of-concept in Go based on the Restic chunker library: https://github.com/akbarnes/dupver https://github.com/akbarnes/dupver
Slackwise 6y ago
What comes next, IMO, is semantic version control. Version control that is aware of changes not at the file and line level, but at the function level, the module level, the library level, the language-specific construct level. (Rich Hickey, creator of Clojure, played around with this idea, but I'm not sure where it went.)
- gnufx 6y ago
  Darcs should be able to support semantic patches, but currently the only alternative patch type is token replacement. How useful semantics might be in a project with N different components' semantics, I don't know.
- IshKebab 6y ago
  There's a project that does diffs on Javascript at the AST level rather than the line level. I haven't tried it though and it is only for resolving conflicts.
- harperlee 6y ago
  He is referring to codeq: https://github.com/Datomic/codeq https://github.com/Datomic/codeq which has a last commit on 2014. But there have been recent rumours (https://medium.com/@sfyire/can-codeq-2-solve-clojures-weaknesses-dd8312ea7add https://medium.com/@sfyire/can-codeq-2-solve-clojures-weakne...) that Hickey is working in a new version of it. Fingers crossed!
atombender 6y ago
Anyone who's ever used Darcs [1] knows that you can do a lot better than Git! So does anyone who's ever used Mercurial, for that matter. Darcs failed to reach mass adoption, and lost against Git back in the mid-2000s, which for me, at the time, felt like a big step backwards (and in other ways a step forward, since Darcs had some icky bugs and performance issues). Some 15 years later it's amazing that we are still stuck with Git. What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Darcs' equivalent to "git cherry-pick" simply pulls along with it any commits that your cherry-pick depend on. Darcs had flaws that prevented it from succeeding, and the fact that it was written in Haskell didn't help attracting developers. Darcs' philosophy lives on in Pijul, which also looks promising, but unfortunately seems doomed to the same fate of remaining a niche tool. Git ate the world thanks to GitHub, and the next VCS needs a similar kind of killer app that justifies the switch. [1] https://en.wikipedia.org/wiki/Darcs https://en.wikipedia.org/wiki/Darcs
- gnufx 6y ago
  Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG
  - atombender 6y ago
    Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.
aaron-santos 6y ago
I'd love to see something that allows for commutativity of non-conflicting commits. It's an artificial constraint that makes some obvious and trivial changes much harder than they should be.
rufus_foreman 6y ago
SVN? A decade ago, something like that, a project I was on switched from SVN to Git. I don't know why, I don't know what problem was being solved. "Git isn't that hard once you understand the internal model" one of the devs said. I didn't need to understand the internal model of Subversion, we just checked stuff out and checked it back in. Within a month of adopting Git they had managed to lose a week's work. I guess they didn't understand the internal model. I kept my mouth shut. For most corporate development teams, there is no problem that Git solves. Corporate development teams don't do distributed development. In a decade of using Git, I have never told another developer to connect to my local Git repo to get a piece of code. I would create a feature branch on the very non-distributed Github or GitLab server and they would go the single source of truth to get that piece of code. Like you would have done with Subversion. Only without the complexity. In the Subversion days, non-technical people would use the same repo as technical people. Like tech pubs. With Git, they can't. As I said, I have no idea what problem Git solves for the typical corporate software development organization. But I admit, it is complicated and hard to use, so in the end, as a developer I make more money. The more complicated it is to make software, the more money I make, and that's what's important. Rock on, Git.
cmwelsh 6y ago
Git fanatics are addicted to the history log and the commit history. It’s not a 1:1 translation to create an accessible Git.
shvedchenko 6y ago
Imagine Linus Torwalds 15 years ago sitting and thinking "so whats the next big new thing after svn?" Would be funny isnt it?
Cyberthal 6y ago
Magit (Emacs)
goatinaboat 6y ago
Let’s be honest, Git replaced Subversion for no reason other than fashion, and Git will be replaced for the same reason.

70 points by mariuz 6y ago

Git submodules just don't seem to work in practice, and that could be a big chance for a competing scm to overtake git. Having dependency management inline with scm would allow for more simplicity in the overall process.

amelius 6y ago
This is also my biggest issue with Git. And integrated/streamlined support for large files.
- wickedOne 6y ago
  what would be a typical large file you want to have in your codebase? usually this shouldn't be a consideration
  - _ph_ 6y ago
    I recently had to deal with a PowerPoint document which is slightly larger than 50 megabytes, which in todays terms, isn't very much. Before, I had kept it in SVN and that has no issues storing larger files. It is a bit shocking that Git has issues with not so tiny files.
  - diffeomorphism 6y ago
    I want to use it for files not just source code. For instance including graphics, the pdfs generated by latex or just anything. Or storing lots of directories. Currently, I use dropbox for that, but if git could do that...
    - wickedOne 6y ago
      though i agree that there isn't a proper vcs out there for large files (adobe bridge was a nice attempt) git wasn't designed for that and one might wonder whether you want git to be _that_ multi purpose.
      - _ph_ 6y ago
        If you have a significant project, you want to store at least a reasonable amount of media with it. Images, documentation. Git doesn't necessarily have to be the best system for handling high-gigabyte sized binaries, but should at least deal gracefully, with small and medium sized binary files. I am also not sure, why not more effort was spent making Git support large files even well.
        amelius 6y ago
        By the way, if you're storing large files under version control in Git it is often useful to use the "--depth=1" flag when cloning or pulling repositories. That way you only download the stuff you really need and leave the rest of the history on the server until you need it.
    - sofixa 6y ago
      Git LFS can do that.
      - war1025 6y ago
        Git LFS is basically the CVS of binary file version control. It is a pile of garbage, but it's better than nothing.
  - amelius 6y ago
    In addition to what others posted here, sometimes it is nice to put generated files under version control with the source code that generated them. For example, simulation results, deep learning models, graphs that you need to include in your LaTeX documents (which can be considered partly source code, partly generated content). Also, deep learning training data often consists of large image files, and can also be considered "source code", and in any case it can be very useful to put these under version control. And finally it can be useful to put external dependencies as tar-files into your source tree.
    - watwatinthewat 6y ago
      I appreciate you laying this out because it's something I have struggled with and thought I just didn't know the right way to handle it. For writing tests in a deep learning code base, rather than simply including a native data file (image, CSV, whatever), I've taken to writing a fake data creator class. It always feels like overkill when an alternative solution is including a native data file or two that already exists.
  - xiphias2 6y ago
    It doesn't matter actually. Tools should be easy to learn and as free of edge cases as possible. An example happening is constant propagation in Rust: it's the same feature, but with every release it can cover more of the code base.
- sofixa 6y ago
  Git LFS has been a thing for years.
  - amelius 6y ago
    Git LFS is not integrated well enough, imho. As I posted elsewhere, this software uses a separate network channel for transferring large files. You can't use it with git-daemon and git-shell, but you'll have to setup another server, configure access control etc. and your repository will be split into different parts of your file system.
  - deleted 6y ago
    [deleted]
  - aesh2Xa1 6y ago
    Git LFS lacks a "host your own server" setup. That's a big downside. Hosting your own revision history should be simple.
    - overgard 6y ago
      I'm doing that with LFS on a gitlab droplet on digital ocean and its trivial (with like a hundred gb repo). Dunno if it was bad in the past but it's not hard now.
  - war1025 6y ago
    If you want a terrible time, have several members of your team not install git lfs, and have them be the main people that commit binary files. LFS uses some sort of internal filtering and tracking to determine which binary files might have changed. It seems to have trouble deciding if there are actually dirty files that need changed. So you can't just say, "Okay, go find all the binary files that didn't actually get moved to LFS and correct them" Instead you end up with random moments where you want to commit a single file and git instead detects 1000 png files that it absolutely could not go on without doing something about. But then the diff is a disaster so good luck understanding that what it is actually mad about is that it wants to move the files into LFS. The only way I finally figured it out was to manually load the object blob and notice one of them was an LFS pointer file. I personally think git annex handles things more elegantly, but lfs won that battle.
- vadishev 6y ago
  This and also path based access (limiting access to certain directories/files within a branch).
wickedOne 6y ago
been using submodules for years without any issues other than the routine before "deinit" was introduced was somewhat tricky. could you elaborate?
- rwmj 6y ago
  I've been using git submodules for years but there are some real problems with them: * Changing from a subdirectory to a submodule breaks lots of things like git reset and git bisect. * Having to remember to git module init, update etc. I always have to look up the commands and never remember what the difference is. * I don't care that there are unlisted files in a submodule, either don't bug me about this in status, or integrate commands in such a way that they work transparently across the main module and submodule. * Related to the previous: Coordinating a single logical change across submodules involves several manual steps and has plenty of scope to go wrong.
junon 6y ago
Submodules are stupid easy, what issues do you have with them?
- ducktective 6y ago
  Once I accidentally added a sub-module to a repo. Had to jump through all kinds of hoops to fix that. - An edit in .gitmodules - An edit in .git/config - A removal in .git/modules (seriously?) https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule https://stackoverflow.com/questions/1260748/how-do-i-remove-... https://gist.github.com/myusuf3/7f645819ded92bda6677 https://gist.github.com/myusuf3/7f645819ded92bda6677
  - junon 6y ago
    Deinit didn't work? And that's the only issue you had with them?
vadishev 6y ago
To be honest, I doubt better submodules are gonna help you overtake Git, there's too much inertia in this market. Take for example Mercurial which is a great tool and exists forever, yet it still lost its battle to Git. I'd rather believe that submodules are fixed at some point or an alternative solution appears that works much better. Git subtree is around for a while and there's also Git X-Modules https://gitmodules.com https://gitmodules.com which is modules on the Git server.

aspyct 6y ago

Git still works great. Why would it need to be replaced, just because it's 15 years old? I can think of a zillion things that are over 15 years and still very much working.

usr1106 6y ago
The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.
- hprotagonist 6y ago
  magit is grand. but editor specific.
  - kubanczyk 6y ago
    I often just magit on a separate terminal and edit with some other IDE/editor. You don't need to learn emacs beyond C-X 0 and C-X C-B really. Productivity is higher than with manual git commands.
  - dotancohen 6y ago
    That's like saying that the Git CLI is specific to CLI users. It is, but anybody can use the CLI or open Emacs no matter what they use to edit the code. I personally started using Emacs for Org-mode, but I code in the Jetbrains IDEs. Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.
- masklinn 6y ago
  > The porcelain would deserve a more consistent and easier to use implementation. Many have taken a crack at it over the years, from very early on. Issue's no porcelain will even replace the built-in one (and what improvements are added to the standard are generally flawed to hell, just look at how messy the brand new `git switch` already is, the git core team simply has no taste when it comes to CLI), and as the creator of a new high-level CLI by the time you'll have good enough feature coverage for it to be useful you'll know the plumbing so well the porcelain will make perfect sense. So you'll abandon the project as offering little value for the maintenance cost. And a few years later somebody else will come in and create their own, and repeat the cycle.

uvesten 6y ago

I’d contend that we might have another 15 years to go before the general developer population have gotten so used to git that they are actually using it in an optimal way for their purpose. Then we’ll find out what its real pain points are, and start working on something new to solve those.

rwmj 6y ago
What features should we be using in git that typical developers don't use? I would guess some kind of answer involving complex branching schemes and/or "octopus merges", but I consider myself a fairly advanced git user and find those too hard to understand. I always stick to simple linear histories with occasional stable branches.
- kubanczyk 6y ago
  Git blame and git log per-file. The commit messages could be the ultimate historical record of all the decisions and the "why"s. Yet, on most projects, saying "I went to read the git log and found out the reason of x" instantly elevates you to a superhero status.
  - rwmj 6y ago
    I guess we mix in different circles because all the developers here use git annotate and git log file|dir regularly. github even has buttons for both operations so you don't need to use the command line.
  - war1025 6y ago
    I would say that this command is much more useful than git blame: git log -p --follow <file>
- moogly 6y ago
  IMO, rebase. I get so depressed everytime I see a merge commit, not to mention when a bisect ends up pointing to one. But it's very difficult to convince some developers it's a smoother workflow.

tails4e 6y ago

The file size limit of git is a bit annoying. I've moved to svn for a few projects that required large binaries to be shared and version controlled along with their source (for hardware design projects) and hit the 100Mbyte (IIRC) file limit. Im sure it could be fixed, but it is a limitation that has prevented me from using git in some cases

profunctor 6y ago
Git lfs is what you want.
- amelius 6y ago
  The problem with this software is that it uses a different channel to transfer the large binaries. If you're using git-shell or git-daemon to host your git repositories on a server, then you can't use that alone to also manage transfer/access of stuff that is managed through git lfs.
- andromeduck 6y ago
  Broken on Windows.
- _ph_ 6y ago
  Why isn't is integrated into Git out of the box? Why do I as a user have to be aware of a separate large file support? Why do I have to install and use a separate tool for this?
- emerged 6y ago
  Everyone immediately says that when this topic comes up, but afaik it doesn’t even transfer or store files as deltas. Each time you change 2 bytes in a multiple GB file, you get to transfer and store an entire duplicate. IMO that is not a genuine solution to large files.
  - NineStarPoint 6y ago
    In fairness, that’s because gitlfs’s primary purpose is to store binaries where changes in the representation don’t actually map to anything useful. There definitely is a separate use case out there for storing large files where only deliberate changes are made to the objects.

ksec 6y ago

Hg (or Perforce)? But Git / BTRFS are Linux, Where Hg / ZFS are BSD. Something better could always come along, whether it gets significant adoption has very little to do with its technical capability.

masklinn 6y ago
> Hg (or Perforce)? They were there at the same time (or before) git, and they don't provide significantly more value than they did then. While I do think they provide value beyond what git offers (my kingdom for revsets instead of the hell that is gitrevisions(7)!) the "market" rejected them then, it has little reason to switch now.
robert_foss 6y ago
Hg/Mercurial & Perforce both existed when Git was created, in fact perforce is part of why Git was created.
- masklinn 6y ago
  > perforce is part of why Git was created. In what way?
  - robert_foss 6y ago
    Ah sheeit. I misremembered. The linux kernel used to use bitkeeper not perforce.
- Zash 6y ago
  Mercurial and Git were both created around the same time in response to the same need for the Linux kernel to find a new vcs.

smaslennikov 6y ago

I'm surprised Phabricator hasn't been mentioned. I haven't used it much, but it's rather huge in some circles.

junon 6y ago
Phabricator and git are almost oranges and apples.

andromeduck 6y ago

IMO what the open source community really needed is a google3 like CI system if only to give library/ecosystem projects like Gnome a greater appreciation of just how much havoc they've wreaked downstream and a better sense of usage patterns in general. IMO the utter disaster that was gnome3/gtk3 transition is what killed what momentum there was for a mainstream Linux desktop.

rhn_mk1 6y ago

I'm watching Pijul, as it seems it has the potential to solve some merge problems, like using the same commit twice in two parents.

lmarcos 6y ago

I think Git will stay as long as we keep representing and working with code as plain text files. Of course I cannot think of a better way of working with code that is not via plain text files (otherwise I would be already rich) but somehow I doubt that programming in 2120 is going to be like programming today: manipulation of code as plain text (although we have to admit that programming has been "manipulation of plain text files" since its very beginnings). Git is still good for tracking changes in plain text files.

gnufx 6y ago
I don't think the original stored program computers even had files, but I don't know when the first recognisable filesystem was. There have been a number of image-based systems which you can program directly, possibly by direct manipulation, even if you ultimately store the image as a (binary?) file.

wickedOne 6y ago

don't fix what ain't broken? i think as long as git keeps evolving and there are no major pitfalls for any programming language: why should it be replaced?

rurban 6y ago
Because it is broken. Merges and rebases rarely work without manual intervention, a patch-oriented tool that is almost as fast as a snapshot-oriented tool, git. Something like Pijul looks promising.
- pskinner 6y ago
  It doesn't work because your changes conflict? How would anything else handle out of order modifications to files that cannot be resolved automatically? There will always been a requirement to do this manually - otherwise the VCS would be able to program for you (understand what is right/wrong).

hannofcart 6y ago

I think git is here to stay for a long time. However, I wonder if there's space for a command line git wrapper makes it much harder to shoot yourselves in the foot via scenarios documented at: https://ohshitgit.com/ https://ohshitgit.com/ I imagine this could be achieved by using more intuitive nouns for subcommands (reflog, rebase) and giving informative warning messages on the command line when you are about to screw something up irrevocably. Eventually, one would hope that some of the more effective features of such a wrapper can find their way back to the git project itself.

wickedOne 6y ago
git has a steep learning curve for sure, but eventually scenarios described at oshitgit should be common knowledge for anyone using it. personally i think putting out sites like that is more helpfull than dumbing down git
IgorPartola 6y ago
git pull rebase should be a top level command for example. Now you don’t get extraneous merge commits if you pull after making a local commit. I have it as an alias for git pull.
- jasonpeacock 6y ago
  You can make that the default `pull` behavior in your Git config: git config --global pull.rebase true You should also enable `rerere`[0]: git config --global rerere.enabled true [0] https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
- u801e 6y ago
  Personally, I think that git pull should not be a command that one can run in normal situations. The common expectation when one is making changes, is to commit and then push. So why shouldn't the same apply when getting changes from the remote. That is, fetch and then apply to the local work tree.
  - 6y ago

js8 6y ago

A paradigm shift, perhaps. Possibly, a notion of "changeset" which is more coherent with the actual code changes. For example, Unison language (https://www.unisonweb.org/ https://www.unisonweb.org/) is a good candidate. I would also like to have the following workflow (in functional language like Haskell, in more imperative language it would be trickier): Before I start working on a code change, I mark the functions and types that are to be modified. A tool then calculates a "change boundary", a set of function calls that potentially have a different semantics in the new code. After I am happy with the boundary, I will start working on a replacement code inside the boundary. The old code will still be available alongside to run and inspect during the whole development process. An automatic test suite generator will run the tests on the old code and by observing the boundary, it will automatically create a regression test suite for the replacement code. Once I am done with the new code, and it is tested, I will let the tool replace it in the defined boundary as a new change. So I will have a guarantee (through types) that I am only changing things that have to be changed, nothing else.

timwaagh 6y ago

Perhaps something that knows to deal with assets a bit better. Or maybe that could just be a new version of git. Also diffs could be more language aware. Maybe via a plug in system. Definitely some room for improvement.

vlovich123 6y ago
Git-lfs?

rwmj 6y ago

I'd like to see a git-like tool that works on the Abstract Syntax Tree rather than being basically a text tool. Of course such a tool might end up being very specific to a particular programming language, which would be not good.

amboo7 6y ago

Sooner or later, we should stop using textual diff and switch over to higher level one/multiple, such as the AST-level diff (see what GrammaTech does, for example). This and integration of dependency management, is a must IMO.

vadishev 6y ago
I think the next SCM tool to Git, is what a Jetbrains IDE is to a text editor. It's an integrated environment on top of Git which deeply understands your code structure, dependencies, etc.

CJefferson 6y ago

I think there is a good space around "version control for everyone else". I have been using overleaf for writing papers, which just does auto sync, and commits to a git repository in the background. It isn't perfect, but it is the best thing I know of for letting experts and beginners work together smoothly.

jcfields 6y ago
Mac OS has had a built-in file versioning system (separate from Time Machine) since Lion or so that works with any program that uses the standard document saving APIs. Most Mac users probably aren't aware that their computer stores potentially hundreds of previous versions of their documents (in evictable space, of course). The interface for it is kind of trash and isn't accessible in every app, though. (Over the summer, I made a command-line [https://gitlab.com/jcfields/versions https://gitlab.com/jcfields/versions] and a GUI program [https://gitlab.com/jcfields/restore https://gitlab.com/jcfields/restore] for accessing this system outside of the standard UI, if anyone's interested, though the binaries are not notarized so the OS will show a scary warning the first time you use them.) Granted, it's not exactly the same thing since you're not making commits at discrete and meaningful points like in a software version control system and since it works on an individual file level, which might not be ideal for every workflow, but it's still really useful when you realize you need to roll something back to an earlier state. I think modern versions of Windows use the Volume Shadow Copy service to store backups of files at given snapshot points (such as when your computer runs a scheduled backup or creates a System Restore point), which can be pulled up in the file properties. I use to use NTBackup to do basically the same thing in a more crude way back in the Windows XP days. This isn't as nice as the Mac Versions feature since it requires setting up periodic backups, but it's something. I'd be curious if any of the free desktops have come up with a simple and user-friendly solution to this. I feel like this is an area where there's a lot of room for improvement, since the majority of users would probably benefit from these systems but most aren't even aware they exist.
bird_monster 6y ago
I work at a games studio, where artists/designers create and manage game assets via our game's source control. I personally dislike Git, but I absolutely think Git is a borderline-unacceptable choice for everyone that hasn't been hazed into the industry with it. The amount of "I accidentally lost all my animation files for ____ feature" is huge. I think most of the positive talk about git UX just waters down to "I know it already", which is evidenced by most of the responses to valid git UX criticisms being "You just don't understand." To me, version control should be as complex as a user wants it to be. Meaning, UX so obvious that you don't need docs or manuals or youtube videos to do the simplest of tasks if you don't want to. There should definitely be room for power users to be power users, but I think git absolutely fails at letting both novices and those that aren't interested in version-control-as-a-specialty be consistently productive and safe. It's always been very curious to me that, for so many parts of dev, we re-invent the wheel a thousand times to try to find the "right" configuration, which ultimately leaves you with a very wide array of options for every one job, but for source control we seem to have just kind of shrugged and said "Git's fine."

jasoneckert 6y ago

The more I learn about the underlying architecture of git and how it was developed and evolved, the more I see the Unix philosophy at work. As a result, I don't think git will ever be replaced, but merely evolve further according to the needs of developers (and others). In the near future, I think we're likely to see more specialized git frontends and additional collaborative functionality than another version control system.

GoblinSlayer 6y ago
Like PHP.
eesmith 6y ago
I think the Fossil system, built on SQLite and its powerful query system, is a superior architecture. "Unix philosophy" has always been in the eye of the beholder. I think Perl showed the 1980s Unix philosophy of "small programs, working together", was often overly cumbersome.

overgard 6y ago

Well, what needs to be fixed? The way I see it: - Built in better binary/large file support - Need to be able to checkout subtrees and host monolithic repos (submodules are a pain) - Better UI

UweSchmidt 6y ago

Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. It will likely come as part of an integrated work environment (some collaborative cloud workflow thing) in order to bypass git's role as gatekeeper/rite of passage for developers.

Slackwise 6y ago
That's more a case of UI rather than implementation, yeah? What's stopping us from just using those words to describe operations with Git? I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1]. (Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.) [1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455 https://news.ycombinator.com/item?id=25537455) [2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Manager https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...
- UncleMeat 6y ago
  UX matters. Databases aren’t just data structures and their operations. They do compete based on interaction patterns and metaphors. VC can do the same.
  - Slackwise 6y ago
    I don't know a single database that is identical to another in implementation and just has a different UI/UX for it. Every single database has something specific for it in terms of implementation. (Unless I guess we're talking forks of MySQL.) I don't know if maybe you have a good example...?
    - 6y ago

ghoward 6y ago

Unlike CVS and Subversion, git is big enough that it won't just be replaced. What comes next needs to be incredible to even have a chance. Personally, I think the next big VCS will have the ability to handle all files, including binary ones. (See https://gavinhoward.com/2020/07/decentralizing-the-internet-and-other-ideas/#version-control-for-binary-files https://gavinhoward.com/2020/07/decentralizing-the-internet-... .) As a bonus side effect, this would probably give that VCS the ability to handle source code by semantics.

jeswin 6y ago

I have bet my startup on the future of git, as a decentralised store for personal data. My view is that git hasn’t peaked at all in terms of usage, and currently only serves the developer niche - while its future might be as a store of personal data for the general public. Sort of how computers were niche products compared to now when everyone has one in their pockets.

GoblinSlayer 6y ago
Git is distributed, not decentralized.

kumarsw 6y ago

The state-of-the-art for backup is deduplicating software (Borg, Restic, Duplicacy). Gripes about Git's UI choices aside, Git was designed around human-readable text files and just doesn't do large binary files well. Sure, there's Git-LFS, but it sucks. The future of version control will: (1) Make use of deduplication to handle large binary files, (2) Natively supports remotes via cloud storage, (3) Doesn't keep state in the working directory so that projects can live in a Dropbox/OneDrive/iCloud folder without corrupting the repo, (4) is truly cross-platform with minimal POSIX dependencies. I've been playing around with a proof-of-concept in Go based on the Restic chunker library: https://github.com/akbarnes/dupver https://github.com/akbarnes/dupver

Slackwise 6y ago

What comes next, IMO, is semantic version control. Version control that is aware of changes not at the file and line level, but at the function level, the module level, the library level, the language-specific construct level. (Rich Hickey, creator of Clojure, played around with this idea, but I'm not sure where it went.)

gnufx 6y ago
Darcs should be able to support semantic patches, but currently the only alternative patch type is token replacement. How useful semantics might be in a project with N different components' semantics, I don't know.
IshKebab 6y ago
There's a project that does diffs on Javascript at the AST level rather than the line level. I haven't tried it though and it is only for resolving conflicts.
harperlee 6y ago
He is referring to codeq: https://github.com/Datomic/codeq https://github.com/Datomic/codeq which has a last commit on 2014. But there have been recent rumours (https://medium.com/@sfyire/can-codeq-2-solve-clojures-weaknesses-dd8312ea7add https://medium.com/@sfyire/can-codeq-2-solve-clojures-weakne...) that Hickey is working in a new version of it. Fingers crossed!

atombender 6y ago

Anyone who's ever used Darcs [1] knows that you can do a lot better than Git! So does anyone who's ever used Mercurial, for that matter. Darcs failed to reach mass adoption, and lost against Git back in the mid-2000s, which for me, at the time, felt like a big step backwards (and in other ways a step forward, since Darcs had some icky bugs and performance issues). Some 15 years later it's amazing that we are still stuck with Git. What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Darcs' equivalent to "git cherry-pick" simply pulls along with it any commits that your cherry-pick depend on. Darcs had flaws that prevented it from succeeding, and the fact that it was written in Haskell didn't help attracting developers. Darcs' philosophy lives on in Pijul, which also looks promising, but unfortunately seems doomed to the same fate of remaining a niche tool. Git ate the world thanks to GitHub, and the next VCS needs a similar kind of killer app that justifies the switch. [1] https://en.wikipedia.org/wiki/Darcs https://en.wikipedia.org/wiki/Darcs

gnufx 6y ago
Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG
- atombender 6y ago
  Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.

aaron-santos 6y ago

I'd love to see something that allows for commutativity of non-conflicting commits. It's an artificial constraint that makes some obvious and trivial changes much harder than they should be.

rufus_foreman 6y ago

SVN? A decade ago, something like that, a project I was on switched from SVN to Git. I don't know why, I don't know what problem was being solved. "Git isn't that hard once you understand the internal model" one of the devs said. I didn't need to understand the internal model of Subversion, we just checked stuff out and checked it back in. Within a month of adopting Git they had managed to lose a week's work. I guess they didn't understand the internal model. I kept my mouth shut. For most corporate development teams, there is no problem that Git solves. Corporate development teams don't do distributed development. In a decade of using Git, I have never told another developer to connect to my local Git repo to get a piece of code. I would create a feature branch on the very non-distributed Github or GitLab server and they would go the single source of truth to get that piece of code. Like you would have done with Subversion. Only without the complexity. In the Subversion days, non-technical people would use the same repo as technical people. Like tech pubs. With Git, they can't. As I said, I have no idea what problem Git solves for the typical corporate software development organization. But I admit, it is complicated and hard to use, so in the end, as a developer I make more money. The more complicated it is to make software, the more money I make, and that's what's important. Rock on, Git.

cmwelsh 6y ago

Git fanatics are addicted to the history log and the commit history. It’s not a 1:1 translation to create an accessible Git.

shvedchenko 6y ago

Imagine Linus Torwalds 15 years ago sitting and thinking "so whats the next big new thing after svn?" Would be funny isnt it?

Cyberthal 6y ago

Magit (Emacs)

goatinaboat 6y ago

Let’s be honest, Git replaced Subversion for no reason other than fashion, and Git will be replaced for the same reason.