3 ms·

SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retri

by rusk 6y ago

SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. In your list of shout commands I don't see anything that could be used for merging? I guess the "language" of git could be tweaked to make it more consistent, but otherwise the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect.

ajuc 6y ago
> It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. select ... as of timestamp; > In your list of shout commands I don't see anything that could be used for merging? I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better interface based on some consistent and clear separation of concerns. > the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect. It's not. SQL simplified A LOT of underlying details. There are dozens of types of indexes. There's partitioning and sharding. There's online backups. There are transactions - local and distributed ones. There's savepoints and rollbacks. If SQL databases were like GIT - selects with joins using different indexes would have different syntax because "you need to understand the underlying structure" :)
- rusk 6y ago
  Perhaps what's needed is an ISO committee to standardise git, or even version control semantics in general, similar to C, and in particular SQL. Once everybody agrees on how it should look, the community can swallow the pain of migration safe in the knowledge that new possibilities are unlocked. Based on how SQL and C/C++ faired in these kinds of processes we could have a standard abstraction layer in perhaps 10-15 years ...

by rusk 6y ago

ajuc 6y ago

> It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. select ... as of timestamp; > In your list of shout commands I don't see anything that could be used for merging? I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better interface based on some consistent and clear separation of concerns. > the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect. It's not. SQL simplified A LOT of underlying details. There are dozens of types of indexes. There's partitioning and sharding. There's online backups. There are transactions - local and distributed ones. There's savepoints and rollbacks. If SQL databases were like GIT - selects with joins using different indexes would have different syntax because "you need to understand the underlying structure" :)

rusk 6y ago
Perhaps what's needed is an ISO committee to standardise git, or even version control semantics in general, similar to C, and in particular SQL. Once everybody agrees on how it should look, the community can swallow the pain of migration safe in the knowledge that new possibilities are unlocked. Based on how SQL and C/C++ faired in these kinds of processes we could have a standard abstraction layer in perhaps 10-15 years ...