4 ms·

Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parse

Text is too broad a category for version control for software to be convenient. I would much prefer version controlling on a subset of text that correctly parses to a domain specific AST. Imagine how much better and informative the diffs and conflict resolution and blames would be. Also imagine moving code across files, e.g. by splitting them and actually having your version control understand that. You could probably push bisects and the like to new levels.

dagw 3y ago
At the same time text is to narrow a category to cover many project needs. There are lots of projects where needing manage and version GBs of various binary data is vital. Git defaulting everything being plain text will miss out a lot of special cases where are more specialised tool might help, but on the whole is probably a good balance and 'good enough' for the vast majority of use cases.
- dagw 3y ago
  That being said, if you want to build a git 'competitor' one of these two avenues can probably offer plenty of interesting opportunities.
PhilipRoman 3y ago
Git's model of snapshot-only storage actually facilitates this quite well. All you need it a custom difftool and a custom mergetool which understands syntax. You also get graceful fallback to textual diffs when your cozy dev environment inevitably encounters the real world.
- giancarlostoro 3y ago
  If someone took the time to build such a tool and put a price tag on it and made it intuitive they would probably make a lot of money.
thworp 3y ago
One could probably build a MVP for this by using tree-sitter parsing, re-injecting identifiers if that is wanted, and then commiting the results to git via a commit hook.