3 ms·

My prediction, tangentially: The next evolution over Git will happen at GitHub. GitHub (and to a much lesser extent, GitLab) is really what allows Git to monop

My prediction, tangentially: The next evolution over Git will happen at GitHub. GitHub (and to a much lesser extent, GitLab) is really what allows Git to monopolize the VCS landscape these days, and it's been true almost from the start. GitHub was really Git's killer app; before it was popular, there was still uncertainty about whether the winner of the VCS wars would be Git, or Mercurial, or Bazaar, or whatever. GitHub was what helped Git win that war. Nobody will be able to break Git's hold over the world except GitHub itself, unless they are able to disrupt GitHub entirely. The player in the best position to do so is Microsoft. They can sneakily launch a competing version (without cannibalizing their own product) within GitHub itself, allowing repos to be selectively "upgraded" to it, and even two-way-mirrored so that Git users can continue to use it until they're ready to migrate. I think Git will relatively easy to disrupt on technological merits as we slowly (very slowly!) move away from old ways of doing things. The current development cycle where individual developers hack away at their local repo and then submit patches already seems antiquated; meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? The other trend we see is the need for code collaboration tools to become more integrated. Git is essentially a glorified file system that happens to have good undo and diffing tools, and the workflows around building, testing, project management, etc. are comparatively primitive for what we developers actually need. For example, right now I do commits locally, then push to a branch, create a PR, and wait for it to build and run tests, then look at the failures, and go back, do some more commits, and rinse and repeat. Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? In particular, we see tools winning over other tools when they reduce friction. I think that's where the next iteration of version control and code collaboration tools will find its way in.

je42 4y ago
> The other trend we see is the need for code collaboration tools to become more integrated. Visual Studio Code Live Share is a precursor for this.
CorrectHorseBat 4y ago
>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? It's bad enough for anything but some quick notes, but it sounds like a nightmare for code. >Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.
- atombender 4y ago
  Of course you can automatically trigger builds on save; my point is that there's an entire shift in thinking that's possible if we treat development as less of a sequence of discrete "stop the world" actions and more as a continuous loop. As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
  - CorrectHorseBat 4y ago
    >As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say. >It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be. I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.

je42 4y ago

> The other trend we see is the need for code collaboration tools to become more integrated. Visual Studio Code Live Share is a precursor for this.

CorrectHorseBat 4y ago

>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way? It's bad enough for anything but some quick notes, but it sounds like a nightmare for code. >Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes? Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.

atombender 4y ago
Of course you can automatically trigger builds on save; my point is that there's an entire shift in thinking that's possible if we treat development as less of a sequence of discrete "stop the world" actions and more as a continuous loop. As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
- CorrectHorseBat 4y ago
  >As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say. >It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be. I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.