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.
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.)
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.
> 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.
> 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.
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.
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.
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.
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.
> 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.
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
> 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
[+] [-] UweSchmidt|5 years ago|reply
[+] [-] Slackwise|5 years ago|reply
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...
[+] [-] dividedbyzero|5 years ago|reply
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.
[+] [-] u801e|5 years ago|reply
If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.
[+] [-] rualca|5 years ago|reply
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.
[+] [-] Gibbon1|5 years ago|reply
You really want to record, mapped X to Y. Not 500 files changed in 4218 places.
[+] [-] knighthack|5 years ago|reply
[+] [-] gct|5 years ago|reply
[+] [-] hannofcart|5 years ago|reply
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.
[+] [-] IgorPartola|5 years ago|reply
[+] [-] wickedOne|5 years ago|reply
personally i think putting out sites like that is more helpfull than dumbing down git
[+] [-] atombender|5 years ago|reply
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
[+] [-] bb88|5 years ago|reply
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.
[+] [-] gnufx|5 years ago|reply
[+] [-] rualca|5 years ago|reply
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?
[+] [-] hibbelig|5 years ago|reply
[+] [-] js8|5 years ago|reply
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.
[+] [-] seanalltogether|5 years ago|reply
[+] [-] vadishev|5 years ago|reply
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.
[+] [-] amelius|5 years ago|reply
[+] [-] wickedOne|5 years ago|reply
could you elaborate?
[+] [-] junon|5 years ago|reply
[+] [-] jasoneckert|5 years ago|reply
[+] [-] aspyct|5 years ago|reply
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.
[+] [-] asiachick|5 years ago|reply
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.
[+] [-] jayflux|5 years ago|reply
It’s also still actively developed so it’s not like some “stale” software we use because of inertia.
[+] [-] bachmeier|5 years ago|reply
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.
[+] [-] usr1106|5 years ago|reply
[+] [-] _ph_|5 years ago|reply
[+] [-] smitty1e|5 years ago|reply
Often this is true, but fetishing change for its own sake becomes inefficient.
[+] [-] Freak_NL|5 years ago|reply
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.
[+] [-] tomcooks|5 years ago|reply
[+] [-] CJefferson|5 years ago|reply
[+] [-] Slackwise|5 years ago|reply
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.)
[+] [-] uvesten|5 years ago|reply
Then we’ll find out what its real pain points are, and start working on something new to solve those.
[+] [-] kumarsw|5 years ago|reply
I've been playing around with a proof-of-concept in Go based on the Restic chunker library: https://github.com/akbarnes/dupver
[+] [-] rhn_mk1|5 years ago|reply
[+] [-] amboo7|5 years ago|reply
[+] [-] tails4e|5 years ago|reply
[+] [-] profunctor|5 years ago|reply
[+] [-] bullen|5 years ago|reply
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!
[+] [-] notretarded|5 years ago|reply
[+] [-] rufus_foreman|5 years ago|reply
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.
[+] [-] jeswin|5 years ago|reply
[+] [-] GoblinSlayer|5 years ago|reply
[+] [-] rwmj|5 years ago|reply
[+] [-] ghoward|5 years ago|reply
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.
[+] [-] aaron-santos|5 years ago|reply
[+] [-] lmarcos|5 years ago|reply
Git is still good for tracking changes in plain text files.
[+] [-] gnufx|5 years ago|reply