Hacker News Reader

Comment by conartist6 | Hacker News Reader

A system as described could be forwards compatible with git without being backwards compatible with git. In other words let people migrate easily, but don't force the new system to have all the same flaws of the old

View on HN

What issues do you see in git's data model to abandon it as wire format for syncing?

I wouldn't say I want to abandon anything git is doing as much as evolve it. Objects need to be able to contain syntax tree nodes, and patches need to be able to target changes to particular locations in a syntax tree instead of just by line/col.

An AST is a tree as much as the directory structure currently encoded in git.

It shouldn't be hard to build a bijective mapping between a file system and AST.

Right, but for what purpose? I don't see much gain, and now you're left trying to fit a square peg into a round hole. The git CLI would be technically working, but not practically useful. Same with an IDE: if you checked the files out you could technically open them but not easily change your program.

the git server would continue to work.

The cli really isn't the greatest either way. But there's lots of infrastructure to make the sharing work reasonably well.

You could also think of it this way: if I abuse git's protocols to do my thing, I pretty much give up my chance to become a standard in the future. If people are going to adopt a new standard they want it to be clean: you don't want to be trying to sell a greenfield technology that's loaded up with legacy tech debt. Making a data format that renders broken in every existing tool that touches it would be showing a lot of bad faith up front.

Reply on news.ycombinator.com