From https://pijul.org/manual/why_pijul.html#patch-commutation : > In Git, importing just a few commits from another branch is called "cherry-picking", and involves changing the identity (the hash) of those commits. This usually works the first time. However, when done again, as the maintainer of a stable branch probably wants to do, this often causes counter-intuitive conflicts. If you're doing this in git to apply…
> If you're doing this [..], you're doing it wrong. [..] This is not 100% true (see my answer to the second part below), but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. In the end, a version control system is just a tool, not a way of life or a work methodology. Sure, there are example projects where the Git way is the best, but they a…
What I would like is instead of representing source code as text to have a binary representation of the AST of the software that I am writing where, crucially, all edit operations are recorded into history.
Perhaps such a binary format could even be slightly faster to work with in terms of time taken for editor and compiler to parse it?
And not only record edit operations, but differentiate between instancing and copying a node, so that we can express whether code that we duplicate should be edited everywhere automatically in the codebase when we change it, or if they should be allowed to diverge. (Both of which make sense in different contexts and would be great to actually express in the source representation and have the IDE read and understand.)
Furthermore, such a representation could allow for more freedom when positioning elements of the code because we aren’t constrained to just lines and lines of text with characters next to each other and lines above and below each other.
Now, a lot of non-textual editors exist already but I haven’t seen any that I like and besides I don’t want another language, I want to write Rust code in such a way as outlined here.