Sturdy utilizes low-level Git data structures, but what does that mean, and why? In a nutshell, it is all about creating a more leveraged development environment — a productivity hack.
Git is powerful as a database, but as a protocol, it places constraints on the development workflow. We believe that these constraints don't fit modern product development which is fast-paced and highly collaborative.
The dictionary definition of the term "expressiveness" is "effectively conveying a thought". In the context of software development, our goal is to map developer intent to concrete actions in Sturdy. The command line is awesome because it is fast and efficient for getting things done, but even faster is not doing those things in the first place!
Here is a typical cycle of code contribution with Git:
Regardless of whether you use the terminal or a Git GUI, these steps are part of the protocol. If we however distill the developer intent, it was to solve a business problem, together with a team.
Sturdy is built by truly lazy developers who thought — “can’t we just do the coding and collaboration, and automate the rest of the steps?”.
Generally, computers are built on many layers of abstraction. Those abstractions exist because they provide leverage when building new things. For example, programming languages exist on a spectrum of control / expressiveness.
Lower level languages allow for precise control — e.g. choosing specific CPU instructions (assembly) or manually allocating and freeing memory (C, C++). The tradeoff is that more code needs to be written to achieve the goal. For some, this is the appropriate abstraction level.
Higher level languages (e.g. Java, Go, Python) abstract away things like memory management and allow the coder to focus at a higher level (e.g. a specific business problem). Under the hood there is of course still a stack and heap, but a Python programmer doesn’t need to think about it. For many, this is the appropriate abstraction level.
In the same spirit, Sturdy is a higher level tool, an abstraction allowing coders to focus on building software and exchanging feedback and ideas with their team. There are still branches, commits, checkouts, trees and refs, but they are fully managed by Sturdy.
This is why Sturdy does not have a CLI – the simplest interface is the absence of one. The only interface that Sturdy has revolves around collaboration and initiating higher level operations.
As to the big question — why? Increasing the expressiveness of the version control and collaboration means getting more stuff done, or just finishing quicker, depending on teams priorities. Sturdy streamlines Continuous Delivery — shipping small incremental changes, frequently, which are easier to review and reason around.
The big, glaring difference between Sturdy and Git is that there is no distinction between local and remote. Just like Git, code is read and modified through a folder on a computer, using an IDE or text editor. However, changes that are made with Sturdy are instantly discoverable by others on the team (through Sturdy Cloud or a self-hosted Sturdy).
The implication is that a coder no longer has to run Git commands to manage state in a local directory. In Sturdy all the operations are at a high level (compared to using vanilla Git where several steps are needed to achieve the equivalent outcome).
All the Sturdy tricks are enabled by the real-time synchronization of files and state, and the fact that code management, review‚ and feedback happen in the same place:
Having mentioned that Sturdy operates at a higher level, it is worth stressing that the output is fully compatible with Git. The underlying primitives are the same and a few higher level concepts are introduced. Here is a TL;DR:
|Draft change||Branch and pull request (but live)|
|Connected directory||Checkout / clone of a repository|
Pull and Push are not user facing operations in Sturdy.
You can learn more about how Sturdy interoperates with GitHub on this page .