¿Por qué Git se entusiasmó tanto? ... mientras que otros no? [cerrado]

124

En los últimos años, el entusiasmo por Git aumentó considerablemente. Todo el mundo sabe sobre Git, nadie sabe sobre alternativas.

Otros como Mercurial parecen pasar desapercibidos. Ambos se lanzaron en 2005 y ofrecen funcionalidades similares. Además, Mercurial generalmente se considera más fácil de usar, más intuitivo y tiene durante mucho tiempo mejores interfaces de usuario. Por lo tanto, se podría suponer que esta sería una alternativa popular, especialmente para aquellos nuevos en el control de versiones distribuido. Sin embargo, parece desconocido para la mayoría de la gente, a diferencia de Git, que tuvo bastante éxito.

El objetivo de esta publicación es intentar comprender mejor este fenómeno.

¿Cómo es que Git se hace parte del pastel? ¿Usaron de alguna manera un mejor marketing? ¿Es porque su comunidad es más ... ejem ... "detallada"? ¿Es por el nombre de "Linus"? ¿Es por su imagen geek?

¿Cual es tu opinion?

arnaud
fuente
63
Posiblemente
tenga
44
No sé, siento que me han expuesto en cantidades aproximadamente iguales ... aunque escuché sobre git antes de hg. Pero sí, Torvalds es una celebridad, por lo que cualquier cosa en la que esté involucrado es probable que llame la atención.
perp
13
Me gusta GitHub ... eso es todo
cnd
77
@jrwren, presentaré este comentario diciendo que no he usado ni Git ni Mercurial. Si tuviera que aprender Git e inmediatamente aprender Mercurial (o viceversa), uno de ellos probablemente me tomaría menos tiempo para aprender. Ese, el que tomó menos tiempo, es el que consideraría más fácil de usar. Grokking generalmente implica que lleva un tiempo entenderlo, lo que es más difícil de usar. No digo que eso empeore un producto, a veces necesita una curva de aprendizaje más pronunciada para herramientas más potentes, pero ciertamente cambia la facilidad de uso.
zzzzBov
8
@MarkTrapp Dios, Mark! Parece que todos estaban teniendo una buena discusión y luego tuviste que venir y vigilar a todos por la puerta. Ojalá supiera de un sitio como StackOverflow que permitiera discusiones.
Theodore R. Smith

Respuestas:

86

Creo que servicios como GitHub o Gitorious son un factor importante. Es importante para las personas que puedan alojar sus cosas en algún lugar y especialmente GitHub es un gran servicio para eso.

Para mercurial, no había tal servicio cuando DVCS se hizo popular (al menos ninguno que yo conociera). Ahora tiene Bitbucket y probablemente otros, pero GitHub ha estado allí durante bastante tiempo, es bien conocido y se pone cada vez mejor.

daaawx
fuente
Agregue a esto que algunos grandes proyectos de código abierto usan git, lo que toma la decisión por usted. Me han "obligado" a usar git varias veces (para Android, por ejemplo), pero no me han obligado a usar Mercurial o Bazaar. Además, creo que git es genial :)
FeatureCreep
11
También hay Google Code y SourceForge para hg
configurador
77
Git es impulsado por Github que pone otros repositorios a la sombra. Bitbucket tiene algunas ventajas (repositorios privados gratuitos) pero la interfaz de usuario es pobre en comparación con Github
iandotkelly
2
Utilizo Mercurial solo para hablar con GitHub ... el complemento hggit ( hg-git.github.com ) permite desacoplar la herramienta de la comunidad. Pero tal vez no de las herramientas de la comunidad.
bpanulla
1
CodePlex también es compatible con Mercurial.
Grant Palin
86

Veo muchas respuestas a esto que se basan en los sentimientos que tuvo el autor cuando escuchó sobre uno u otro SCM. Otros dicen que todo fue pura suerte. Creo que la suerte se remonta a la historia.

Hablaré de historia.

Git y Mercurial se crearon simultáneamente para resolver el mismo problema. En aquellos días, el kernel de Linux se vio obligado a dejar de usar BitKeeper , un SCM distribuido patentado que había estado usando durante 3 años. La razón de esto fue que Larry McVoy, CEO de BitMover, la compañía detrás de BitKeeper, dejó de entregar su software de forma gratuita a los desarrolladores de Linux, porque alguien dentro de la comunidad de Linux lo había modificado.

Linus Torvalds, insatisfecho con lo que ya existía, posteriormente comenzó a trabajar en un SCM nuevo que pronto llamaría Git. Poco después, Matt Mackall comenzó el proyecto Mercurial por razones similares.

Después de algún tiempo desarrollando estos proyectos por separado, Matt Mackall presentó una versión avanzada de su SCM y lo comparó de cierta manera, comparándolo con Git (que en sí mismo tenía solo un par de semanas). Linus consideró usarlo en lugar de Git para el desarrollo de Kernel, pero abandonó la idea cuando se dio cuenta de que Mercurial estaba usando Changesets para registrar modificaciones de revisión . Temía que eso estuviera demasiado cerca de la forma en que funcionaba BitKeeper, y ciertamente no quería nada que pudiera hacer que alguien dijera: "Construyeron un clon de BitKeeper".

Por lo tanto, Git se usó para el desarrollo de Kernel en lugar de Mercurial, pero ambos eran técnicamente relevantes. El resultado final es que Git comenzó siendo utilizado donde fue diseñado para usarse, mientras que Mercurial no fue tan rápido para encontrar su primer gran uso de FOSS. Debido a que estaba dotado de un muy buen diseño, y gracias a la perseverancia de Matt Mackall, eventualmente se hizo famoso y se utilizó para grandes proyectos del mundo real.

Hoy, ambos son famosos. Cuál es el más famoso es imposible de decir. Google Code solo integró Git recientemente, mientras que tenía Mercurial durante mucho tiempo. Muchos proyectos realmente grandes y famosos usan cualquiera.

Supongo que lo que quiero decir es que, cuando la razón por la que ha comenzado un proyecto desaparece, es más difícil ganar popularidad, pero aún es factible.

Bazaar es otro SCM que es muy famoso en el mundo GNU, pero no tanto fuera de eso, porque fue construido con la intención de satisfacer a la comunidad GNU. El software a menudo va a donde sus creadores quieren ir, y no más.

Por otro lado, los SCM distribuidos son claros ganadores. No veo muchos SCM no distribuidos ampliamente utilizados por ahí.

Thaddee Tyl
fuente
55
Realmente aprecio esta historia.
jrwren
44
@ TMN Tienes razón! De hecho, cuando la ingeniería inversa de Andrew Tridgell salió a la luz, y cuando Larry McVoy cambió la licencia de BitKeeper, hubo tantas guerras de llamas que Linus Torvalds decidió abandonarla y se dio una semana para encontrar un reemplazo. En ese momento, el verdadero competidor era Monótono, pero era muy lento. Muchas personas construyeron reemplazos al mismo tiempo, y todos estaban felices de usar las nuevas herramientas. Creo que Git golpeó 1.0 primero, luego Mercurial; Bazar tomó casi dos años.
Thaddee Tyl
77
"No veo muchos SCM no distribuidos ampliamente utilizados". Depende de dónde se encuentre en la industria. Perforce, ClearCase y svn todavía se usan mucho, pero no tanto (excepto svn) en el mundo de código abierto. Ah, sí, y Visual Source Safe y MS Team lo que sea que esté en las tiendas de Windows.
Bob Murphy
13
Por "ingeniería inversa", se refiere a hacer una llamada telefónica al servidor y escribir "ayuda"
alternativa
3
Diría esto en general sobre DVCS y CVCS: "Todo el software participa del Tao y no debe ser despreciado". "¿Incluyendo software de Redmond?" "Oh, Dios, mira el reloj. Clase despedida".
Bob Murphy
77

Linus Torvalds

Linus es un gran defensor de Git y lo promovió en gran medida al grupo principal de Linux durante años y se ha desarrollado a partir de ahí. Me atrevo a decir que se debe completamente a la influencia de Linus sobre la comunidad * nix.

Personalmente sigo usando Subversion, pero eso es por preferencia y no por utilidad.

Justin Shield
fuente
12
No creo que sea Linus personalmente tanto como la gran visibilidad de Linux: hay algunas cosas que podría decirle a alguien sin conocimiento previo sobre DVCS (o incluso el desarrollo de software en general) que tienen más probabilidades de otorgar credibilidad que "se usa para el Kernel de Linux ".
Michael Borgwardt
66
No solo es un gran defensor de eso, sino que es él quien creó las versiones originales antes de entregarlo a Junio ​​Hamano
Marco Ceppi
44
¿Qué? ¿Por qué preferirías Subversion?
configurador
11
¿No quiere decir que todavía usa Subversion por hábito e inercia, en lugar de preferencia o utilidad? Es por eso que todavía lo estoy usando, y sospecho que la mayoría de nosotros también ...
Cody Gray
77
@deadalnix: Debido a que Linux y Linux tienen una multitud de gritos fanboys incomparables con cualquier otro proyecto de código abierto. Funcionan como un equipo de calle bastante efectivo para Git.
Tom Anderson el
34

El punto de dolor habitual con el sistema de control de versiones es la fusión de ramas .

Debe haberlo intentado cuando no funciona para comprender lo doloroso que puede ser y lo importante que es trabajar, para poder trabajar libremente con las ramas.

Al enterarse de que Linus Torvalds escribió git para hacer esto bien, y que supuestamente en una situación ha usado git para fusionar doce ramas a la vez, este es un argumento muy convincente para que git sea interesante.

Estuve en la situación hace aproximadamente un año donde tuve que elegir entre hg y git, y la fusión anterior fue un factor importante para elegir git. El segundo fue que la organización de Eclipse cambió a git, por lo que se esperaba que las herramientas de Eclipse fueran buenas para los proyectos de Java. Con el lanzamiento de Eclipse 3.7 esto ha sucedido. Estábamos quizás 6-9 meses antes de esto.

Para diferentes necesidades, hg podría ser igual de útil. Sun lo eligió para su VCS basado en una investigación muy cuidadosa. Es posible que desee encontrar los libros blancos y ver cuáles fueron sus razonamientos.


EDITAR: Tenga en cuenta que no estoy diciendo que Mercurial haya algo que no pueda hacer, solo eso para Java con Eclipse, que es nuestro enfoque principal, las fuerzas del mercado son actualmente más fuertes para git, incluso bajo Windows, y debemos apoyarnos. de otros, no sus pies.

usuario1249
fuente
55
+1 Todo está en las ramas. Este análisis discute el poder de fusión de git en comparación con mercurial.
Amelio Vazquez-Reina
19
@AmV: no publique URL ofuscadas.
Cody Gray
44
No estoy seguro de ver tu punto aquí. Estás diciendo que son igualmente buenos para bifurcar (Git no hace nada que Mercurial no pueda hacer), pero porque necesitas una buena bifurcación, ¿elegiste Git?
jalf
8
Nunca he visto ningún ejemplo convincente de cómo Git es mejor para fusionarse que Mercurial, y ciertamente no en esta respuesta. Es casi como si estuviera confundiendo a Hg con SVN o CVS.
Aaronaught
23

En lugar de decir por qué git o mercurial es mejor y decir que es la única razón por la que es popular, me enfocaré en la comunidad.

Como destaqué anteriormente , la comunidad Git es muy ruidosa y arrogante. La mayoría defenderá vigorosamente su preciado programa. La mayoría de las guerras Git vs Mercurial que he visto fueron iniciadas por personas git que se preguntaban por qué todos en la Tierra no están usando el git sagrado. Sitios como whygitisbetterthanx.com incluso muestran esta arrogancia en la introducción, que está escrita para atraer a otros.

No digo que todo el mundo sea así, pero la mayoría de las veces, cuando me encuentro con personas git, sitios web pro-git y blogs pro-git, sentí que me estaban metiendo git en la garganta en lugar de ofrecerlo como un DVCS viable. sistema.


En contraste, otras comunidades de DVCS no son tan ruidosas. No sabía que Mercurial existía hasta que vi un "¿Cuál es el mejor DVCS?" pregunta sobre SO. Si bien git aparece en todas partes, otros DVCS tardan en encontrarlo.

TheLQ
fuente
16
¿No es arrogante llamar a otros arrogantes un poco arrogante?
21
@ Thorbjørn: Lo es. Excepto cuando lo hago; entonces es correcto.
Tom Anderson el
66
Creo que te has vuelto bastante alérgico al git. He leído la introducción de whygitisbetterthanx y parte de su contenido. No veo nada arrogante o provocativo. Simplemente tiene el sesgo normal, que cualquier cosa destinada a promover algo tiene.
back2dos
55
@ back2dos: es bastante arrogante porque dice "Git es mejor que todo". Y en esa gran parte de su argumentación de apoyo es incorrecta y no está corregida, o tachada, y de alguna manera nunca cambia su conclusión.
jalf
55
@Agos: Y casi todos los cuales no son exclusivos de Git. Simplemente mueven los postes para excluir otros productos.
Aaronaught
14

No creo que Mercurial tenga un perfil particularmente bajo. Kiln está construido sobre Hg y ha habido un buen soporte en IDEs como Eclipse y Netbeans desde hace un tiempo.

La mayoría de los desarrolladores con los que hablo parecen preferir Hg debido a la mejor compatibilidad con Windows. Si fuéramos desarrolladores de Linux, podría ser una historia diferente.

También te estás perdiendo "Bazar", que es el verdadero "DVCS olvidado".

Ciertamente, estoy de acuerdo en que Linus es un tipo muy carismático y un nerd alfa casi sin igual, por lo que mucha gente gravitaría a Git por eso. Además, el "mito de la creación" de Git es muy convincente con Linus trabajando durante 6 días para crear Git y descansando en el séptimo, o algo así. Cuando un producto tiene una historia memorable, es más fácil ganar tracción.

mcottle
fuente
66
... totalmente de acuerdo con: "Bazar", que es el verdadero "DVCS olvidado".
Dagnelies
de acuerdo, pero la exposición que hg tiene del horno / joel es más reciente que la exposición que tiene git de linus. hg está jugando a ponerse al día
jk.
2
En realidad, hay bastantes "DVCS olvidados", aunque muchos de ellos probablemente se describan mejor como "perfil bajo", "enfocado" o "nicho".
John Gaines Jr.
13

Es una opinión humilde, pero git podría obtener toda esta exageración debido a dos parámetros:

  1. Es muy eficiente
  2. Es divertido de usar (de alguna manera muy específica en informática)

Además, git obtuvo una aplicación asesina como github, y algunos proyectos muy populares decidieron usarla, lo que le dio mucha visibilidad.

Thibault J
fuente
44
1. ¿Es mercurial ineficiente en alguna área? En realidad, durante mucho tiempo, fue más eficiente sobre http, por lo que el código de Google lo incluyó desde hace más de 2 años, en comparación con el soporte de git que se anunció la semana pasada y que recientemente se volvió igualmente bueno sobre http. 2. OK 3. Existe el bitbucket.org equivalente
dagnelies
1
¿Dije que mercurial era ineficiente? Nunca lo usé, así que puedo decir.
Thibault J
44
Esto no aborda la pregunta en absoluto en mi humilde opinión, al menos no la parte "mientras que otros no"
jk.
1
Mercurial no puede agregar "carpetas vacías" al repositorio (no sé si esto se ha solucionado ahora) pero cuando tuve que elegir un DVCS, eventualmente fui git para este propósito. Necesitaba algunas carpetas vacías.
Martin Marconcini
44
@ MartínMarconcini ¿Qué quieres decir con "eventualmente me volví loco por este propósito"? git tampoco admite carpetas vacías.
Max Nanasy
12

Aquí hay tres factores en juego: "beta geek media", "es el momento adecuado" y "sigue al líder"

Beta Geek Media

Hay varios canales que analizan las "actividades geek". Sin duda, cubrirían la apariencia de un nuevo sistema de control de versiones, pero cubren más. ¿Por qué? Debido a que Linus Torvalds lo escribió inicialmente, discutió sobre ello públicamente y lo usó como una solución a su bien publicitado problema con Bitkeeper. Efectivamente, cada vez que haya una guerra de llamas en lkml, los medios beta geek escribirán un artículo al respecto. La discusión de Git comenzó en lkml, por lo que obtuvo más cobertura que otras alternativas. Y los beta geeks que leen slashdot como si fuera Variety se lo comieron. El resultado final de eso es que git tiene diez veces más artículos que mercurial.

El tiempo es correcto

Los grandes proyectos de código abierto con muchos contribuyentes tienen problemas con el control de fuente centralizado. A medida que el código abierto crece y los proyectos se vuelven más propensos a tener muchos contribuyentes, el problema empeora. Linux es probablemente el proyecto más conocido que sufre de esto, pero hay muchos otros. Con muchos proyectos llegando a este punto, se necesitaba algún tipo de VCS avanzado. Git, Mercurial y Bazaar fueron los grandes ganadores aquí. Arch y Monotone llegaron demasiado pronto y se perdieron la ola de publicidad.

Sigue al líder

Los grandes proyectos tienen seguidores que revisan y construyen el código regularmente, incluso si no contribuyen. Los seguidores se familiarizan con las herramientas necesarias para obtener el proyecto que siguen, por lo que esas herramientas tienen más uso. Echemos un vistazo a los proyectos de "gran atractivo" para los tres grandes DVCS:

  • Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
  • Mercurial : Java, Mozilla, Python
  • Bazar : Ubuntu, Emacs

Git tiene más proyectos de "gran atractivo" que lo utilizan, por lo tanto, más personas están familiarizadas con git, hay más tutoriales de git escritos.

Sean McMillan
fuente
1
Puede que tengas razón, pero tu lista de "gran atracción" es un poco engañosa / sesgada. Mirando el sitio de Bazaar, enumeran muchos otros proyectos importantes: MySQL, Bugzilla, Debian, GNU, todos parecen bastante conocidos. La lista de Hg es bastante más grande también.
jalf
@jalf: dicha lista debe ser subjetiva. He compilado mi propio Linux y Gnome, pero nunca Mozilla o Emacs. Otros pueden ser exactamente lo contrario. La pregunta es realmente "¿cuántas personas sacarán este proyecto del control de la fuente"? Enumeré los que me parecen más inspiradores para que instalen un vcs para extraer la fuente actual.
Sean McMillan
Lo suficientemente justo. Supuse que era un intento de una lista objetiva (después de todo, las listas de los cuales los principales proyectos utilizan cada sistema DVCS debe ser bastante fácil de localizar a) :)
JALF
12

Es principalmente solo un bombo autorreforzante. Git es el más popular, por lo que recibe la mayor publicidad, lo que hace que se vuelva más popular.

Git, Hg y Bzr son sistemas DVCS perfectamente buenos, pero un número aterrador de personas equipara DVCS con Git, y piensa que todas las características encantadoras de un DVCS son exclusivas de Git. Y entonces usan Git, y recomiendan Git, y dicen cosas como "Git es mejor porque puede hacer fusiones de pulpo" (también puede Bazaar), o "Git es mejor porque está distribuido" (así es cualquier DVCS, de ahí el nombre ), o "Git es mejor porque facilita la ramificación y la fusión" (nuevamente, esto es cierto para cada DVCS).

Lamentablemente, porque siento que las alternativas también tienen mucho que ofrecer, y prefiero que las personas elijan Git por sus fortalezas únicas, en lugar de simplemente porque piensan que DVCS == Git.

Cuando alguien descubre cuán inteligentes son los DVCS, al señalar un DVCS específico, a menudo no van y le dicen a los demás "oye, los DVCS son geniales, deberías usarlos", sino más bien "el DVCS que yo aprendí sobre DVCS de es genial, deberías usarlo ".

mitad
fuente
11

Github Github es pionero en la codificación social. Convirtió el control de versiones en una plataforma social que atrajo mucha atención, y obviamente solo es compatible con Git. Redes sociales = mayor adopción. Bitbucket está ganando fuerza a pesar de obtener muchas características nuevas, lo que lo convierte en un rival probable :)

DelvarWorld
fuente
7

Bueno, de hecho, creo que la exageración se trata de todas las juntas DSVC.

Pero los defensores del git son más vocales, a menudo más agresivos en sus comentarios para ser honestos y les gusta hablar de eso en todas partes.

Sospecho que Mercurial se usa ampliamente, ciertamente tan a menudo como git, tal vez más (Microsoft y otras grandes compañías lo usan ahora), pero las personas que usan Mercurial con mayor frecuencia solo querían un DSVC que puedan captar rápidamente, no algo en lo que basar una religión. Por lo tanto, son menos vocales y más reactivos en las discusiones que proactivos, como algunos usuarios de git.

Ciertamente, no se habla mucho del bazar porque solo unos pocos grandes proyectos conocidos lo usan y no se sabe que otras grandes compañías que Canonical lo usen. Compare con Google (git, mercurial, svn) y grandes proyectos de código abierto, por ejemplo, y puede ver por qué no se habla realmente. Fossil es otro que es interesante para un nicho de desarrolladores, por lo que creo que es normal y bueno que solo aquellos que buscan las funciones que brindan les escuchen (como wiki incorporado, seguimiento de problemas y foro).

Dicho esto, creo que estamos bajando lentamente el ciclo de exageración y muchos desarrolladores que han usado varias soluciones diferentes pueden comenzar a ver cuál se ajusta a sus necesidades.

Además, Google Code Hosting y SourceForge ahora permiten tanto git como mercurial, por lo que se está convirtiendo en una opción más específica para el proyecto que antes cuando elegía git debido a las características de GitHub.

No hay una guerra real, solo una interesante variedad de herramientas.

Klaim
fuente
Desearía que la exageración se tratara de DVCS en general, pero por todo lo que he visto, la exageración se trata de Git, y la mayoría de la gente piensa que DVCS y Git son básicamente lo mismo.
jalf
6

Sé que ya hay muchas respuestas a esta pregunta, pero sentí que podría agregar un poco más de perspectiva.

Usé Bazar casi desde que fue creado para varias cosas. Lo más importante para lo que lo utilicé fue el proyecto AllTray, del cual soy (actualmente) el único desarrollador y mantenedor. El bazar es lindo. Simplemente funciona, se mantiene fuera de mi camino, y casi nunca tengo que mirar una página de ayuda o la página de manual. Dicho esto, hay algunas desventajas:

  1. Tiene mucha funcionalidad que posiblemente debería ser parte del VCS central, no lo es. Cosas como la capacidad de realizar una bisección de la historia, ejecutar una salida larga a través de un localizador o tener ramas "colocadas" (por ejemplo, repositorios de estilo git) se suministran como complementos.
  2. Muchos de los complementos no son tan estables. Por ejemplo, la funcionalidad de ramas ubicadas no parece funcionar bien en el lado del servidor (al menos, nunca lo hice funcionar, tiende a equivocarse diciendo que la rama en la ruta dada no existe cuando es justo delante de ti y puedes ver la cosa sangrienta).
  3. No tiene ninguna operación de "clonación", tira de ramas una a la vez. Debe realizar un trabajo adicional si desea tener un repositorio para poder extraer nuevas ramas de manera eficiente.
  4. Para algunos proyectos, es dolorosamente lento. Pruebe "bzr branch lp: mysql" alguna vez.
  5. Carece de un fuerte soporte para ganchos; puede escribir complementos bzr que proporcionen enlaces, pero no existe una forma estándar de tener scripts de enlace arbitrarios del lado del servidor.

Recientemente cambié a git para el desarrollo de AllTray, y estoy considerando rápidamente migrar todos mis proyectos a git. Hay un poco más de tiempo inicial dedicado a conocer las cuerdas, pero parece valer la pena. Algunas cosas que he notado:

  1. git clone es una operación relativamente rápida y le brinda información sobre todas las ramas que existen en el repositorio que clonó.
  2. Agregar repositorios remotos adicionales es sencillo, por lo que puede realizar un seguimiento de muchos repositorios diferentes que tienen múltiples ramas si lo desea.
  3. El libro Pro Git está disponible en línea y en múltiples formatos, incluso para dispositivos lectores de libros electrónicos, y no es una lectura difícil.
  4. git parece mucho más fácil de extender que Bazaar, y no tienes que usar ninguna API en particular para hacerlo. (NB: esto es tanto una ventaja como una desventaja).
  5. git tiene bisección incorporada, y no puedo enfatizar lo suficiente la utilidad de esa característica.
  6. GitHub es bastante agradable.
  7. El gitosissistema también es bastante agradable. Ni siquiera estoy seguro de cómo se implementaría eso además de como un complemento en Bazaar, y no puedo imaginar que sea tan eficiente.

Larga historia corta: he usado bzr durante mucho tiempo, pero git rápidamente me está demostrando su genialidad.

Michael Trausch
fuente
5

Al usar git, tiende a permanecer siempre en el mismo directorio local cuando realiza el desarrollo, y simplemente lo hace git checkout branchnamepara cambiar entre ramas (utilizo ramas de funciones "ligeras" todo el tiempo, por lo que esta es una característica muy importante para mí).

Al observar la documentación y los tutoriales de Mercurial, parece que la forma preferida de tratar con diferentes ramas de desarrollo es crear nuevos repositorios mediante la clonación. Este tutorial es un ejemplo.

Creo que puedes hacer lo mismo en Mercurial que en git, pero por alguna razón la documentación de Mercurial (que he leído) casi siempre muestra ramificaciones al crear un clon de repositorio.

(Uso git a diario. Tengo poca experiencia con mercurial, he jugado con él y seguí algunos tutoriales)

codeape
fuente
2
Usé ramas 'nombradas' todo el tiempo en hg. Los apoya bien. hg branch foo, luego hg up foomás tarde ... Clone-for-branch tiene algunas debilidades fuertes para el desarrollo ordinario.
Paul Nathan
Hmm, ¿entonces estás diciendo que Git es mejor que Hg porque aunque Hg admite la característica que te interesa, la comunidad de Hg considera un enfoque alternativo superior?
jalf
1
1: Me pregunto: ¿Por qué centrarse en "ramificar por clonación" en la documentación de Hg (ver, por ejemplo, hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html y mercurial.selenic. com / guía )? Para mí, me parece desordenado tener un repositorio por rama. 2: No estoy diciendo que git es mejor, mi respuesta es más una observación sobre un asunto que para mí (un novato Hg) parece una diferencia entre los dos. La diferencia parece ser más cultural que técnica, ya que Hg también admite "ramificación dentro del mismo repositorio".
codeape
3
Mercurial sufre de una gran cantidad de información desactualizada en línea; Mucho de esto fue propagado por personas que usan git y no se mantuvieron al día con las características de mercurial a medida que evolucionó. La mayoría de las viejas razones para preferir los repositorios clonados ya no se aplican en las versiones modernas de mercurial (las ramas con nombre se pueden cerrar ahora, y hay un sistema de marcadores que le da un patrón de uso similar a las ramas de git si lo desea).
Stephen M. Redd
4

No sé cuántas diatribas de este tipo he visto en las últimas semanas, pero todos parecen considerarlo como un hecho de que Mercurial y / o Bazar son objetivamente mejores que Git. La usabilidad parece ser un tema común. Sí, aprender Git fue sorprendentemente difícil después de usar CVS y Subversion, pero en este punto no me gustaría cambiarlo por ningún otro VCS a menos que constituya otro cambio de paradigma . Y señalar una tabla de características me dirá muy poco acerca de cuán flexible, extensible, seguro o sin esfuerzo es. Por ejemplo, por defecto git-diff usa colores y un buscapersonas. Claro que puedo obtener lo mismo con diff ... | colordiff | less -Ro algo así, pero debería ser obvio por qué uno es superior al otro.

l0b0
fuente
No creo que el argumento sea que, por lo tanto, debería cambiar, obviamente usar la herramienta que ya conoce es más fácil que cambiar a otra, no importa cuán fácil sea esa otra. No creo que ningún defensor de DVCS pueda realmente afirmar que te estás perdiendo una gran cantidad al estar en git en lugar de Bazaar o Mercurial, no hay mucho entre ellos.
ZoFreX
3

Para ser justos, creo que los defensores de git vs. mercurial son pocos y distantes entre sí en comparación con los defensores de git vs. Sin embargo, las razones son fáciles de resumir:

Git es control de versiones para programadores. Mercurial es control de versiones para empresas. Centralizado fue un primer intento adecuado para inventar el control de versiones, especialmente teniendo en cuenta que fue diseñado antes de la revolución de la computadora personal.

Lo que quiero decir con control de versiones para programadores es que los programadores en general favorecen la flexibilidad sobre la facilidad de aprendizaje. Después de todo, estamos dispuestos a pasar años aprendiendo idiomas esotéricos para tener la flexibilidad de hacer que las computadoras hagan lo que los no entrenados no pueden. Git ofrece a los programadores la flexibilidad de usarlo como quieran, a expensas de que tarde más en aprender cómo usar esa flexibilidad de manera segura. Permite que se establezcan restricciones para hacer cumplir las políticas, pero no sale así de la caja. Tenga en cuenta que dije facilidad de aprendizaje en lugar de facilidad de uso . Una vez que lo aprende, git es tan fácil de usar como cualquier otro VCS y, a menudo, más fácil debido a la mayor velocidad y características.

Algunos programadores aprenden lo suficiente como para hacer lo que quieren, luego se resisten a aprender nuevas formas de hacerlo. Las empresas contratan y emplean a muchas de estas personas, por lo que desean cualquier cambio en las herramientas que utilizan para tener un cierto grado de familiaridad. Las empresas también quieren que sus programadores tengan suficiente flexibilidad para hacer su trabajo, pero no tanto como para dificultar la capacitación o la migración inicial. Aquí es donde encaja Mercurial. Tiene la mayor parte del poder de git, pero una ruta de migración algo más fácil.

No creo que sea justo decir que git solo es popular debido a la exageración o al respaldo de Linus. Eso probablemente explica que muchas personas lo prueben , pero se adhieren a él y lo promueven porque les funciona bien, puro y simple.

Karl Bielefeldt
fuente
2

El desarrollo de NetBSD usa CVS y eso es todo lo importante.

Jonathan Cline IEEE
fuente
2

Tiene un nombre más ágil y conciso que se presta bien para juegos de palabras.

Sobrecarga de apofenia
fuente
1

Recientemente estaba buscando un sistema de control de versiones para proyectos personales, así que probé un montón de ellos. Soy prácticamente analfabeta en la línea de comandos, y había escuchado que, aunque las GUI estaban disponibles, Git realmente estaba destinado a ser utilizado a través de la línea de comandos, lo que me hizo dudar un poco. Honestamente, sin embargo, fue ridículamente fácil de aprender, y realmente lo estoy disfrutando. La documentación es un factor enorme en la adopción de una nueva tecnología, y Git tiene toneladas de documentación ridículamente simple que está clara y disponible. Las otras alternativas como SVN y Bazaar fueron geniales, simplemente no lo hicieron tan fácil como Git. Github también es un factor importante, ya que se ha vuelto tan central para el movimiento de código abierto en este momento. Tener una ubicación centralizada (irónicamente) para intercambiar código y proyectos es un cambio de juego en sí mismo.

Morgan Herlocker
fuente
1

Solo mi 2 ¢: elegí git sobre las alternativas porque está escrito en C en lugar de un lenguaje de radio o un lenguaje de alto nivel demasiado académico. Los beneficios son que es rápido y eficiente y que realmente puedo RTFS si encuentro errores o comportamientos que no puedo explicar. También permite su uso en pequeños entornos de desarrollo autohospedados que no incluyen intérpretes / tiempos de ejecución gigantescos, lo que significa que puedo extraer directamente de un repositorio de git y compilar en dichos sistemas en lugar de tener que buscar la última fuente en otro lugar y rsync.

R ..
fuente
1
Esa fue también la razón por la que elegí git, porque está escrito en un lenguaje compilado en lugar de python, y por eso simplemente puedo tener una versión portátil de git en mi lápiz USB junto con algunas otras herramientas.
Coyote21
Y, sin embargo, esta es precisamente la razón por la que Facebook eligió usar mercurial en su lugar: no estaban contentos con el rendimiento de ninguno de los dos, pero les resultó más fácil mejorar el rendimiento de mercurial (que, para la mayoría de las operaciones, era solo un pequeño porcentaje más lento que git en general) por un margen significativo (lo que hicieron al integrarlo con un servicio de monitoreo de archivos para que pudiera decir qué podría y no pudo haber cambiado, ver detalles aquí ) debido al hecho de que Python era más fácil de trabajar que C.
Jules
1

Quizás le interese leer por qué el proyecto de escritorio GNOME eligió git sobre hg y bzr, cuando decidió mudarse de svn hace unos años. Hubo muchas discusiones religiosas acaloradas en el camino, por supuesto, pero esta página de GNOME Wiki resume muy bien los pros y los contras que se aplicaron a esa comunidad en particular.

calum_b
fuente
0

Sin mencionar que Apple ahora se ha involucrado en llevarlo a la comunidad objetiva c, si ha creado una nueva aplicación en Xcode 4 recientemente, habrá notado que automáticamente le pregunta si desea hacer un repositorio de Git.

Concedido Xcode 4 solo ha existido durante unos meses, y no influye en el éxito anterior de Gits, pero todos sabemos lo popular que Apple puede hacer las cosas en un corto espacio de tiempo.

tutts
fuente
-1

Actualmente estoy cambiando de hg (horno) a git (github). He usado horno durante aproximadamente un año en este momento. Para mí hg no tiene desventaja. Puedo hacer todo lo que tengo que hacer. Entonces es genial.

¿Por qué estoy usando ahora?

Solo hay tres razones en este momento.

  1. gitHub ofrece gists que son geniales
  2. gitHub ofrece excelentes funciones sociales
  3. Mientras realizaba presentaciones y talleres para desarrolladores, siempre publicaba mis muestras en hg y git. ¡En git tengo alrededor de 10 veces más visitantes que en hg!

Creo que el tercero es el más importante.

Thorsten

Thorsten
fuente
-2

Pura suerte, supongo, hasta ahora casi imposible probar por qué algo funcionaba y otro no. Linus puede construir algo más espectacular y no tener éxito.

Acaz
fuente