Git no es el futuro del control de versiones, según la empresa que construye su reemplazo
What Comes After Git
Steve Klabnik, creador de East River Source Control, sostiene que Git fue diseñado para las limitaciones de 2005 y no para el desarrollo agéntico actual. Su propuesta: hablar el protocolo Git pero reemplazar el almacenamiento por un motor propio escalable horizontalmente, con un camino de adopción incremental hacia Jujutsu. El producto aún no está disponible.
Dicho claramente, no creemos que Git sea el futuro del control de código fuente. Git ha servido bien a los desarrolladores durante muchos años, pero fue diseñado en torno a las limitaciones de 2005, no de 2025, y mucho menos de 2035.
- nrr
Aquí me hago eco de los otros comentarios: este artículo es realmente anémico en detalles sobre cómo ERSC pretende reformar Git para el futuro (más allá de Jujutsu como vía de migración) o por qué no hay lugar para Git (tal como lo conocemos) en el futuro[0].
Da la casualidad de que tengo contexto técnico sobre este problema[1], y el anuncio me dejó bastante frío. ¡Al menos mencionen lo jodidamente engorroso que es el formato de cable del pack-protocol! ¡Denos a los que somos técnicos y estamos metidos hasta el cuello en el negocio de Git algo de lo que compadecernos!
Dicho todo esto, ¡mencionaron Fossil! \o/
--
0: Sí, mencionan patrones de desarrollo agéntico y las restricciones con las que chocan los patrones orientados a monorepo, pero los detalles se despachan con un manotazo. ¿Qué tienen los patrones de desarrollo agéntico en particular que estresan a Git? Para aquellos de nosotros que no usamos agentes o tenemos una exposición limitada a ellos, esto no es especialmente obvio, pero los patrones de uso casi con certeza se reflejan en otros usos de Git que los talleres más pequeños encontrarían.
1: Incluso he examinado largo y tendido la posibilidad de intentar yo mismo reformar el almacén de objetos de Git para que sea más bien como un log de solo anexado, con la mira puesta en aliviar algunos de los problemas que, por ejemplo, los flujos de trabajo intensivos de GitOps a veces pueden causar, y ni hablar del fervor en torno al desarrollo agéntico. O sea, este espacio está maduro para que alguien venga y lo haga mejor, pero el control de versiones es una herramienta técnica para gente técnica.
- rbsmith
Esto es más una respuesta a muchos de los comentarios aquí que al artículo, ofreciendo una perspectiva de qué valor podrían aportar.
He pasado unos 35+ años en y alrededor del control de versiones / SCM, con la mitad de ese tiempo siendo parte del equipo de BitKeeper, donde mi trabajo era pensar en conjuntos, grafos y tramas en el contexto de un equipo que mejoraba la vida de los clientes comerciales junto con el beneficio para el mundo del código abierto.
Si Git es suficientemente bueno para ti, ten por seguro que no lo es para todos. Para algún subconjunto de ese todos, vale la pena pagar para que ese dolor desaparezca. Y parte de que ese dolor desaparezca es poder mantenerte conectado a todo lo que hay, ser lo suficientemente superconjunto del mundo actual, para no ser mejor de una manera incompatible. Eso es lo que veo en las imágenes que dibujan Steve y su equipo: un mundo que interactúa con Git de una manera que es mejor para algunos dispuestos a pagar para que el dolor desaparezca.
Estoy de acuerdo en que no se dice mucho sobre el Non-Git Storage Engine. Como he pasado la mitad de mi vida en ese mundo, lo entiendo: salsa secreta. No espero que se diga mucho por un tiempo.
- EddieRingle
Como los otros comentarios, estoy muy confundido sobre qué se supone que hace esto aparte de promocionar un aspirante a competidor de Git y otra "conferencia" hiperespecífica. La publicación no presenta realmente ningún argumento, ni siquiera en la sección que se supone que argumenta. ¿Y por alguna razón están metiendo GraphQL en la mezcla, de alguna manera?
- asmnzxklopqw
¿Qué problema intentan resolver? Esta parte todavía no me queda muy clara.
- fergie
Para mí, lo que realmente no es fantástico de git es versionar datos(bases), pero este artículo no parece abordar eso. De hecho, me está costando analizar el problema/solución propuesto por el artículo.