What comes after Git?

https://twitter.com/jasoncwarner/status/1342172372061749248

by mariuz • 6 years ago

70 173 6 years ago

aspyct• 6 years 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• 6 years ago

The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.

hprotagonist• 6 years ago

magit is grand. but editor specific.

masklinn3• 6 years 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.

Freak_NL• 6 years ago

Git just works most of the time, and any issues that arise tend to have to do with the complexity of the codebase rather than git (e.g., rebasing a large feature-branch over dozens of commits).

Besides, auxiliary tools aside (I use git shell and a bunch of aliases), the git executable too is still improving. It will be a long time before anything that might replace it reaches both the maturity and the tipping point of having enough extra features to make it worthwhile to consider switching.

jayflux• 6 years ago

I agree, Git will be replaced when there’s a general limitation affecting many developers and something comes along that solves that. It won’t be replaced for the sheer sake of it or because we’re “bored” of it.

It’s also still actively developed so it’s not like some “stale” software we use because of inertia.

bachmeier• 6 years ago

Git still works great.

Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workflows is currently the biggest threat to open source. There's no such thing as "submitting a patch" these days. You're expected to be a master of a project's Github workflow to contribute. Most of us (myself included, with a few exceptions) just don't bother.

compsciphd2• 6 years ago

I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.

tomcooks2• 6 years ago

Isn't this "knowing how to use it" come with the usual dose of RTFM and/or trying things?

Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes

throwaway894345• 6 years ago

Don’t you just need to open a pull request? Or is there more ceremony that I’m missing?

shred45• 6 years ago

What you says is true, it can be very difficult to submit ad-hoc patches to large projects. In my experience, however, this has been due to brittle, undocumented automated checks and newbie-hostile maintainers who have built a complex contribution process. I'm not convinced that a different version control system would change this. There are also many projects on GitHub that are very pleasant to work with.

tomcooks2• 6 years ago

It's the usual "controversial" Twitter post to boost one's account, I suggest not looking too much it and moving on

_ph_4• 6 years ago

For me the question is less whether Git stopped working, but whether there is any progress being made beyond Git. As Git is around for 15 years now, it is a justified question, if there are any exciting new developments beyond Git.

eesmith2• 6 years ago

I think Fossil adds things beyond Git, because it also supports "bug tracking, wiki, forum, and technotes." https://fossil-scm.org/home/doc/trunk/www/index.wiki

I think it's odd that so many people use a DVCS as part of a development system so dependent on a centralized server for everything else.

asiachick• 6 years ago

If you come from games you'll see where git fails miserably. Modern AAA games have terabytes of assets. p4 has handled this. git, has not. p4 also manages the fact that unlike source code you often can't merge certain assets so you need networked access controls (as in A can't edit this now because B is edit it).

Note I love git, but I don't know any big game studios using it. Some indies get by because their games are smaller but even then it can be a pain.

thiht• 6 years ago

Does it have to be a goal for Git? Most of the development is not game development

lupire• 6 years ago

What about git-annex for the large asset files?

smitty1e• 6 years ago

There seems a focus on new=improved in human thinking.

Often this is true, but fetishing change for its own sake becomes inefficient.

uvesten• 6 years 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.

rwmj4• 6 years 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.

kubanczyk2• 6 years 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.

moogly• 6 years 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• 6 years 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• 6 years ago

Git lfs is what you want.

amelius5• 6 years 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.

andromeduck2• 6 years ago

Broken on Windows.

_ph_4• 6 years 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?

emerged2• 6 years 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.

notretarded• 6 years ago

Put them in an artefact repository and pull them down at build time?

bullen• 6 years ago

I agree; cvs, svn and git work ok and don't need that much change, what needs improvement is separation between code and media!

I'm making a simple .zip over HTTP solution for my MMO now.

It just has a naming scheme with dates and you send your last .zip date to the server and the server sends a list for you to download.

The good part with dates is that you can consolidate the data retroactively without breaking the system!

ksec• 6 years 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.

robert_foss2• 6 years ago

Hg/Mercurial & Perforce both existed when Git was created, in fact perforce is part of why Git was created.

masklinn3• 6 years ago

perforce is part of why Git was created.

In what way?

Zash• 6 years 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.

masklinn3• 6 years 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.

seanalltogether• 6 years 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.

amelius5• 6 years ago

This is also my biggest issue with Git. And integrated/streamlined support for large files.

wickedOne5• 6 years ago

what would be a typical large file you want to have in your codebase? usually this shouldn't be a consideration

sofixa2• 6 years ago

Git LFS has been a thing for years.

vadishev3• 6 years ago

This and also path based access (limiting access to certain directories/files within a branch).

wickedOne5• 6 years ago

been using submodules for years without any issues other than the routine before "deinit" was introduced was somewhat tricky.

could you elaborate?

rwmj4• 6 years 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.

junon3• 6 years ago

Submodules are stupid easy, what issues do you have with them?

ducktective• 6 years 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-...

https://gist.github.com/myusuf3/7f645819ded92bda6677

vadishev3• 6 years 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 which is modules on the Git server.

smaslennikov• 6 years ago

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

junon3• 6 years ago

Phabricator and git are almost oranges and apples.

andromeduck2• 6 years 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• 6 years 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• 6 years 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.

gnufx4• 6 years 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.

wickedOne5• 6 years 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• 6 years 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• 6 years 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• 6 years 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/

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.

wickedOne5• 6 years 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• 6 years 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• 6 years 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

u801e8• 6 years 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.

js8• 6 years 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/) 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• 6 years 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• 6 years ago

Git-lfs?

rwmj4• 6 years 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• 6 years 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.

vadishev3• 6 years 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• 6 years 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• 6 years 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] and a GUI program [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_monster3• 6 years 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• 6 years 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.

GoblinSlayer3• 6 years ago

Like PHP.

eesmith2• 6 years 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.

overgard2• 6 years 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• 6 years 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.

Slackwise3• 6 years 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)

[2] https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...

UncleMeat2• 6 years 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.

IshKebab2• 6 years ago

What's stopping us from just using those words to describe operations with Git?

The huge existing body of documentation, tutorials, StackOverflow questions, etc. that use the confusing standard Git terminology.

gct• 6 years ago

lol no

dividedbyzero• 6 years ago

I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look.

I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.

6510• 6 years ago

I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either.

I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand?

When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves.

I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence.

In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!

mdtusz• 6 years ago

To me, this is mostly a solved problem for casual contributors using the web interface of GitHub (and I assume gitlab, Bitbucket, and others). If more "serious" contributions need to be made, learning the basics of how git works isn't that difficult - branching, commits, and merging are basically all that a novice user needs to understand, and they're pretty easy to explain concepts (even if it means you're telling White lies about how it works under the hood).

We don't expect the average person to understand the tools and workflow of a mechanical engineer working with SolidWorks PDM - we shouldn't expect the average person to understand git (which is basically the software equivalent). I've never disagreed with the arguments that git is confusing or difficult to learn for non-software-developets, but I've never really understood why that's a problem.

u801e8• 6 years 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.

If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.

bird_monster3• 6 years ago

Given how much COBOL is still in production, I suppose it depends entirely on your definition of "dominant" ?

rualca4• 6 years 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.

Those are the usecases that Git already handles. Each and every single one of them. Somehow you conspicuously left branching out of it, which is the main value added by any version control system along with merging. Thus I really don't see the point of arguing that Git will be replaced by a tool that does exactly what Git has been doing by design since it was released.

Gibbon12• 6 years ago

I think what will kill git is integration with language servers and IDE's. The reason is git and everything before it doesn't capture high level change/refactoring information.

You really want to record, mapped X to Y. Not 500 files changed in 4218 places.

matt-attack• 6 years ago

Darcs supports “replace” semantics where you can rename a variable say across the whole project with just as you suggest, a single meaningful commit.

knighthack2• 6 years ago

Hasn't there been many attempts of that sort over the years? I recall some similar efforts being made to simplify Git for use with writers, etc.

ghoward• 6 years 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-... .) As a bonus side effect, this would probably give that VCS the ability to handle source code by semantics.

jeswin• 6 years 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.

GoblinSlayer3• 6 years ago

Git is distributed, not decentralized.

kumarsw• 6 years 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

Slackwise3• 6 years 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.)

gnufx4• 6 years 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.

IshKebab2• 6 years 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• 6 years ago

He is referring to 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-weakne...) that Hickey is working in a new version of it. Fingers crossed!

atombender5• 6 years 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

gnufx4• 6 years 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

atombender5• 6 years 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.

hibbelig• 6 years ago

Pijul is the spiritual successor to darcs I think.

rualca4• 6 years ago

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).

Is that property relevant, though? I mean, although it does not need commits to be sequential, well... They already are, and there is no way around that. And sharing commits across branches, whether it's in the form of cherry-picked commits or pure old diff/patch workflows, is something that Git already handles.

Additionally, is there any workflow that does require any of those properties/features?

Meanwhile, how about Darcs' computational cost?

atombender5• 6 years ago

It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't.

With Darcs, all merging can be thought of as rebasing, except histories remain compatible and mergeable. With Git, on the other hand, rebasing the same commits multiple times result in the same conflicts that need to be fixed every time, which is why "rerere" exists. Darcs does not need "rebase" or "rerere" or any of the other tools for complicated history surgery.

As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (exhibit A: hundreds of HN posts about learning to use Git) and is especially daunting for beginners, compared to easier tools like Subversion and Mercurial that provide nicer UIs. Darcs brings modern version control to users without incurring the complexities of Git.

It's not perfect — it had/has corner cases where merging became computationally expensive, though I hear there are new developments to fix this — which is why I said the future isn't Darcs.

bb884• 6 years ago

So does anyone who's ever used Mercurial, for that matter.

So I've used mercurial and git in production. The one thing that turned me off on mercurial was that branching information was stored as part of the commit. This led sometimes to weird conflicts where the branch list needed to be merged. Granted that's been several years ago, so it might be different now, I don't know, and with git I have no need to.

I definitely appreciate branching data being meta data outside of the branch.

Also Darcs had severe issues maybe a decade ago where merging would appear to cause infinite locking. It wasn't a coding bug, it was due to their originally flawed theory of patches. So while it may be awesome, the world has definitely moved on.

It's worth reading this from pijul:

Did you solve the “exponential merge problem” darcs has?
Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future.

So good, but polynomial time can still be large beasts computationally.

pmeunier• 6 years ago

Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.

iggldiggl• 6 years ago

I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too.

Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.

aaron-santos• 6 years 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• 6 years 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• 6 years 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• 6 years 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• 6 years ago

Magit (Emacs)

goatinaboat• 6 years ago

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

What comes after Git?

Related Stories