3 ms·

>I definitely reject the "git compatible" approach If your version control system is not compatible with GitHub it will be dead on arrival. The value of allowi

>I definitely reject the "git compatible" approach If your version control system is not compatible with GitHub it will be dead on arrival. The value of allowing people to gradually adopt a new solution can not be understated. There is also value in being compatible with existing git integrations or scripts in projects build systems.

quadrifoliate 9mo ago
Based on reading this, I don't see anything that would prevent keeping track of a repo tracked by this database with Git (and therefore GitHub) in addition to the database. I think the "compatible" bit means more that you have to think in terms of Git concepts everywhere. Curious what the author thinks though, looks like it's posted by them.
- gritzko 9mo ago
  Technically, exporting changes either way is not a challenge. It only becomes difficult if we have multiple gateways for some reason. One way to do it is to use the new system for the messy part and git/GitHub for "publication".
conartist6 9mo ago
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
- ongy 9mo ago
  What issues do you see in git's data model to abandon it as wire format for syncing?
  - conartist6 9mo ago
    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.
    - ongy 9mo ago
      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.
      - conartist6 9mo ago
        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.
        ongy 9mo ago
        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.
        conartist6 9mo ago
        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.
wavemode 9mo ago
I don't think Git/GitHub is really all that big of a lock-in in practice for most projects. IMO Git is not an unassailable juggernaut - I think if a new SCM came along and it had a frontend like GitHub and a VSCode plugin, that alone would be enough for a many users to adopt it (barring users who are heavy customers of GitHub Actions). It's just that nobody has decided to do this, since there's no money in it and most people are fine with Git.
- charcircuit 9mo ago
  The wall of getting buy in for switching your company over to a new SCM is much higher if you need to move everything over to a new system and switch over all of your developers onto new software at the same time. And if things don't work out you have to do the same expensive process in reverse. On the other hand if you have git compatibility you can start with a small group of developers being able to try out the tool first and see if it is actually beneficial and work your way spreading it through the company. If it turns out the new thing isn't good it is trivial to go back to your old tools since you did not have to do expensive migrations.
  - conartist6 9mo ago
    I think you're right that this dynamic will exist of being harder to get buy-in all at once, but git faced that dynamic when competing against earlier VCS systems and still won the market. The dynamic that I think balances this out is the "inherited expectations" dynamic. You'll end up winning a lot of people by offering them easy migration, but then you'll find it difficult or impossible to satisfy them because they just want the exact same product they were using but somehow magically cheaper and better. My goal is to avoid the violent, priority-changing growth that comes with direct interoperability, and just ride the regular bell-shaped adoption curve. Right now I want to connecting with early adopters who are eager to look at a new technology precisely because they're crashing up against the more immovable limitations of the old and so who are willing to seek out and accept new things, even if it means accepting change. But that acceptance of change is key to creating expectations I can actually satisfy so that my growth actually drives more growth
ivanjermakov 9mo ago
Doesn't seem like they want VCS in traditional sense anyway. More like a collaborative undo history with emphasis on CRDT?

quadrifoliate 9mo ago

Based on reading this, I don't see anything that would prevent keeping track of a repo tracked by this database with Git (and therefore GitHub) in addition to the database. I think the "compatible" bit means more that you have to think in terms of Git concepts everywhere. Curious what the author thinks though, looks like it's posted by them.

gritzko 9mo ago
Technically, exporting changes either way is not a challenge. It only becomes difficult if we have multiple gateways for some reason. One way to do it is to use the new system for the messy part and git/GitHub for "publication".

conartist6 9mo ago

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

ongy 9mo ago
What issues do you see in git's data model to abandon it as wire format for syncing?
- conartist6 9mo ago
  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.
  - ongy 9mo ago
    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.
    - conartist6 9mo ago
      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.
      - ongy 9mo ago
        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.
        conartist6 9mo ago
        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.

wavemode 9mo ago

I don't think Git/GitHub is really all that big of a lock-in in practice for most projects. IMO Git is not an unassailable juggernaut - I think if a new SCM came along and it had a frontend like GitHub and a VSCode plugin, that alone would be enough for a many users to adopt it (barring users who are heavy customers of GitHub Actions). It's just that nobody has decided to do this, since there's no money in it and most people are fine with Git.

charcircuit 9mo ago
The wall of getting buy in for switching your company over to a new SCM is much higher if you need to move everything over to a new system and switch over all of your developers onto new software at the same time. And if things don't work out you have to do the same expensive process in reverse. On the other hand if you have git compatibility you can start with a small group of developers being able to try out the tool first and see if it is actually beneficial and work your way spreading it through the company. If it turns out the new thing isn't good it is trivial to go back to your old tools since you did not have to do expensive migrations.
- conartist6 9mo ago
  I think you're right that this dynamic will exist of being harder to get buy-in all at once, but git faced that dynamic when competing against earlier VCS systems and still won the market. The dynamic that I think balances this out is the "inherited expectations" dynamic. You'll end up winning a lot of people by offering them easy migration, but then you'll find it difficult or impossible to satisfy them because they just want the exact same product they were using but somehow magically cheaper and better. My goal is to avoid the violent, priority-changing growth that comes with direct interoperability, and just ride the regular bell-shaped adoption curve. Right now I want to connecting with early adopters who are eager to look at a new technology precisely because they're crashing up against the more immovable limitations of the old and so who are willing to seek out and accept new things, even if it means accepting change. But that acceptance of change is key to creating expectations I can actually satisfy so that my growth actually drives more growth

ivanjermakov 9mo ago

Doesn't seem like they want VCS in traditional sense anyway. More like a collaborative undo history with emphasis on CRDT?