¿Por qué se considera que Mercurial es más fácil que Git?

204

Al mirar las comparaciones, me parece que podría haber una asignación 1: 1 entre sus conjuntos de características. Sin embargo, una declaración frecuentemente citada es que "Mercurial es más fácil". ¿Cuál es la base de esta declaración? (Si alguna)

Tamás Szelei
fuente
21
Extraño, nunca escuché que Mercurial fuera más fácil. Encontré más documentación para Git (puede haber sido percepción), así que aprendí eso.
Nic
16
¿Porque fue hecho por Linus?
Trabajo
124
Girando hacia territorio de guerra santa aquí, pero encontré que Mercurial era más fácil de usar que Git porque, como usuario de Windows, me sentí bienvenido por Mercurial, y Git me trató como un bicho raro y un perdedor. Sé que estoy antropomorfizando software, y sé que ambos son perfectamente capaces de usarse muy bien en Windows, pero esa es la impresión que emiten los dos.
Carson63000
24
hginit.com
Svish
11
Me pregunto cuántas personas estarían usando Git si Github no existiera o si no tuviera tantos proyectos de alto perfil.
Chris S

Respuestas:

240

Caso en cuestión: Digamos que desea cambiar el nombre de usuario en todas sus confirmaciones anteriores. He necesitado hacer esto varias veces por varias razones.

Versión Git

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Versión Mercurial:

archivo de autores.convertir.lista:

<oldname>=<newname>

Línea de comando:

hg convert --authors authors.convert.list SOURCE DEST

Ahora, ¿cuál parece más fácil de usar?


Nota: Pasé 2 años trabajando únicamente con Git, así que esto no es una queja de "Lo odio, no lo conseguí en 2 segundos".

Para mí, es la usabilidad. Git está muy orientado a Linux con una forma Linux de hacer las cosas. Eso significa línea de comando, páginas de manual y descifrarlo usted mismo. Tenía una interfaz gráfica de usuario muy pobre (nota: estoy basando esto en msysGit de hace aproximadamente un año), que parecía interponerse en mi camino. Apenas podía usarlo

La línea de comando era peor. Al ser un programa orientado a Linux, en Windows era muy difícil de usar. En lugar de un puerto nativo, simplemente envolvieron git con MinGW (Think cygwin), lo que hizo que trabajar con él fuera mucho más difícil. MinGW no es símbolo del sistema de Windows, y simplemente actúa de manera diferente. Es una locura que esta sea la única forma de trabajar con Git. Incluso en Linux parecía que la única forma era trabajar con línea de comando directa. Proyectos como RabbitVCS ayudaron a algunos, pero no fueron muy poderosos.

El enfoque orientado a la línea de comandos y al ser un programa de Linux significaba que casi todas las guías de procedimientos, la documentación de ayuda y las preguntas del foro / QA se basaban en ejecutar comandos monstruosos como el anterior. Los comandos básicos de SCM (commit, pull, push) no son tan complejos, pero la complejidad crece exponencialmente.

También odio el único lugar donde muchos usuarios de OSS git parecen estar: Github. Cuando va por primera vez a una página de Github, lo golpea con todo lo que puede hacer. Para mí, una página de proyectos git parece caótica, aterradora y demasiado poderosa. Incluso la explicación de lo que es el proyecto, se lleva al fondo. Github realmente lastima a las personas que no tienen un sitio web completo ya configurado. Su rastreador de problemas también es terrible y confuso. Sobrecarga de funciones.

Los usuarios de Git también parecían ser muy cultos. Los usuarios de Git parecen ser siempre los que comienzan las "guerras santas" sobre las cuales DVCS es mejor, lo que obliga a los usuarios de Mercurial a defenderse. Sitios como http://whygitisbetterthanx.com/ muestran arrogancia y una mentalidad casi de "Usar mi software o morir". Muchas veces he ido a varios lugares de ayuda solo para sentirme culpable por no conocer X, usar X de antemano, usar Windows, etc. Es una locura.


Mercurial, por otro lado, parece ir hacia el enfoque más amable. Su propia página de inicio parece mucho más amigable para los nuevos usuarios que la de Git . En una simple búsqueda en Google, el quinto resultado es TortoiseHg, una GUI muy agradable para Mercurial. Todo su enfoque parece ser la simplicidad primero, el poder después.

Con Mercurial no tengo tonterías SSH (SSH es un infierno en Windows), no tengo comandos estúpidamente complejos, no tengo un usuario de culto que me siga, no tengo locura. Mercurial simplemente funciona.

TortoiseHg proporciona una interfaz realmente utilizable (aunque últimamente parece estar creciendo) que proporciona funciones realmente útiles. Las opciones se limitan a lo que necesita, eliminando el desorden y las opciones que rara vez se usan. También proporciona muchos valores predeterminados decentes

Mercurial, siendo muy amigable con los recién llegados, fue muy fácil de aprender. Incluso algunos de los temas más complejos, como el modelo de ramificación diferente y la edición del historial, fueron muy fáciles de seguir. Recogí Mercurial rápida y sin dolor.

Mercurial también funciona la primera vez con poca configuración. En CUALQUIER SO puedo instalar TortoiseHg y obtener todas las funciones que quiero (principalmente comandos del menú contextual) sin tener que buscar diferentes Guis. También falta configurar SSH (la mitad de las guías dicen usar Putty, Plink y Pagent mientras que la otra mitad dice usar ssh-keygen). Para los nuevos usuarios, TortoiseHg tarda unos minutos en configurarse, mientras que Git tarda de 30 minutos a una hora con muchas búsquedas en Google.

Por último, tienes los repositorios en línea. El equivalente de Githubs es BitBucket, que tiene algunos de los problemas que describí anteriormente. Sin embargo, también está el código de Google. Cuando voy a un proyecto de Google Code , no obtengo una sobrecarga de funciones, obtengo una interfaz agradable y limpia. Google Code es más un combo de repositorio / sitio web en línea, que realmente ayuda a los proyectos de OSS que no tienen una configuración de sitio existente. Me sentiría muy cómodo usando Google Code como sitio web de mis proyectos durante bastante tiempo, solo construyendo un sitio web cuando sea absolutamente necesario. Su rastreador de problemas también es poderoso, encajando perfectamente entre el rastreador de problemas casi inútil de Github y la monstruosidad de Bugzilla .

Mercurial simplemente funciona, la primera vez, siempre. Git se interpone en mi camino y solo me enoja cuanto más lo uso.

TheLQ
fuente
66
Comentaristas: los comentarios están destinados a buscar aclaraciones, no para una discusión prolongada. Si tiene una solución, deje una respuesta. Si su solución ya está publicada, favor de votarla. Si desea discutir esta pregunta con otras personas, utilice el chat . Consulte las preguntas frecuentes para obtener más información.
1
IntelliJ IDEA y Xcode 4 tienen una integración maravillosa con Git en sus respectivas plataformas y para las tareas diarias, nunca tiene que usar la línea de comandos.
44
Me gustaría agregar que tortoiseGIT es mucho mejor ahora cuando quieres usar GIT en Windows. Todavía tiene que lidiar con las claves SSL y el proceso de instalación no es sencillo, pero cuando lo hace, funciona fácilmente.
Arkh
2
Extensiones de Git Personalmente me parece mucho más fácil navegar y trabajar con TortoiseHG en Windows, y solo he usado 1 línea de comando con git.
KallDrexx
1
Estoy algo desconcertado por esta línea: "MinGW no es el símbolo del sistema de Windows, y simplemente actúa de manera diferente. Es una locura que esta sea la única forma de trabajar con Git". Utilizo la instalación de msysgit y la opción 2, para ejecutar desde la línea de comandos de Windows. Funciona bien. Hay algunas cosas que no funcionan (como el símbolo de intercalación, un carácter de continuación de línea en DOS) pero hay alternativas a esas (como la tilde) que funcionan bien. No soy un entusiasta de la línea de comandos (o al menos no lo era antes de comenzar a aprender Git), pero usar Git con la línea de comandos es realmente fácil. ¿Me estoy perdiendo de algo?
Kyralessa
80

Git versus Mercurial

En general, se cree que Mercurial es más simple y fácil de aprender que Git. A su vez, a menudo existe la percepción de que Git es más flexible y poderoso. Esto se debe, en parte, a que Git tiende a proporcionar más comandos de bajo nivel, pero también en parte a que el Mercurial predeterminado tiende a ocultar funciones avanzadas , dejándole a los usuarios que editen el archivo de configuración mercurial para activar las funciones avanzadas que deseen. Esto a menudo lleva a la percepción de que las funciones avanzadas no están disponibles en Mercurial.

Conceptos de Git

Mercurial siempre se ha centrado más en los aspectos de la interfaz, lo que originalmente hacía que fuera más fácil de aprender. En comparación con Git, se requiere una comprensión más superficial para operar con Mercurial de manera útil. A la larga, tal encapsulación le ha dado a Mercurial la falsa apariencia de ser menos poderoso y con más características de lo que realmente es.

Cíclope
fuente
73
Así que Mercurial oculta solo la funcionalidad avanzada, mientras que GIT oculta toda la funcionalidad ... ;-)
asombro
44
Git no tiene más poder. Por ejemplo, no hay equivalente a git's HEAD ~ 1 . Mercurial tiene p (x) que se extiende a través de las ramas, qué inútil. No hay etapa en Hg. Todas las ramas deben ser empujadas cuando empujas. Mercurial no es tan flexible, incluso con todos los complementos como histedit, shelf y rebase. La línea de comando de Git también es mejor, le da al usuario pistas, los mercuriales no. Me veo obligado a usar este DVCS ligeramente lisiado en el trabajo y me he encontrado en situaciones en las que mercurial carece del poder para hacer lo que quiero.
Keyo
22
@ Keyo: Mercurial tiene ~, ver los cambios . No tiene un área de preparación, pero puedes emularla con MQ, que es mucho más potente. Aprenda a usar la herramienta en lugar de atenerse a lo que sabe de git, valdrá la pena.
Idan K
22
@ Keyo: No tienes que empujar todas las ramas con Mercurial cuando empujas. Puede empujar una rama específica ( hg push --branch BRANCH) o hasta una revisión específica ( hg push --rev REV). Por favor vea hg help pushpara más opciones.
Regente
1
Para su información, se puede obtener un subconjunto considerable del área de preparación utilizando la extensión de registro . OTOH, creo que la extensión de estantería (modelada a partir del comando "estantería" de Baazar, y cerca de "git stash") sirve mucho mejor para la mayoría de los propósitos de usar el área de preparación.
brandizzi
47

Contexto: uso Mercurial (para el trabajo) y Git (para proyectos paralelos y de código abierto) a diario. Principalmente uso herramientas basadas en texto con ambos (no IDEs) y estoy en una Mac.

En general, creo que es más fácil trabajar con Mercurial. Algunas cosas que encuentro hacen que Mercurial sea más fácil:

  1. Falta de índice. El índice es una herramienta poderosa que permite muchas de las funciones de Git, pero también es una capa adicional que agrega un paso en muchas cosas que hago regularmente. El flujo de trabajo de Mercurial es más similar a algo como svn.
  2. Números de revisión en lugar de shas. Esto es algo pequeño que creo que hace que trabajar con comandos diarios sea mucho más fácil en Mercurial. Es mucho más fácil ingresar algunos números de revisión en su cabeza durante un rebase, fusión, etc. mientras escribe un comando que hacer lo mismo incluso con shas acortados.
  3. Ramas El enfoque de Git a las sucursales al nombrar commits es poderoso y sustancialmente diferente a otros sistemas de control de versiones. Hace que ciertas cosas sean mucho más fáciles. Me parece que el enfoque de Mercurial coincide con svn pensando un poco mejor y hace que sea más fácil entender visualmente el historial de la rama. Esto puede ser solo una preferencia.
Alex Miller
fuente
66
+1 por mencionar el índice; Creo que el índice y sus interacciones son la cosa que hace git más difícil de aprender que mercurial.
Sean McMillan
18
El hgequivalente a gitramas se llama realmente bookmarks. Hasta donde yo sé, las hgramas no tienen un equivalente en git.
Hank Gay
66
Estoy en la misma situación, con mercurial en el trabajo y git en casa. La ramificación mercurial es bastante molesta para mí, me gusta tener ramas privadas y empujarlas cuando me gusta. Mercurial me obliga a usar estanterías o repositorios adicionales. Los números de revisión son tontos, dame el hash. El escenario es genial en git, extraño esto. Realmente extraño el poder de git. Hice algunas cosas con algunos complementos, pero la ramificación realmente me molesta.
Keyo
66
@ Keyo: en mi experiencia, la gitramificación es un subconjunto de la hgramificación. En hgpuede tener ramas con nombre y sin nombre (topológicas), e incluso puede administrar ramas sin nombre de la misma manera que gitusando marcadores. Nunca he visto realmente el punto en el área de preparación. Prefiero dejar de lado los cambios no deseados y luego asegurarme de que mi código compila y completa mis pruebas antes de confirmarlo. Entonces puedo dejar de lado y continuar. Además, "Massaging Hunks" de Charles Bailey (p90 +) me asusta * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
Mark Booth
77
@Keyo: en Mercurial, las ramas privadas se denominan 'marcadores': actualice a la revisión raíz hg bookmark keyo-stuff, haga cosas hg commit, y eventualmente hg push -B keyo-stuff. Si no le gustan los números de revisión, no los use; Creo que Mercurial aceptará un hash en cualquier lugar donde acepte un número de revisión. Tengo que decir que sus comentarios que critican a Mercurial por la falta de características que de hecho han parecido ignorantes y un poco agresivos; ¡no estás haciendo mucho bien por el estereotipo de los usuarios de Git!
Tom Anderson
29

Esto es muy subjetivo y depende de una persona a otra, pero sí, lo diría a alguien completamente nuevo en VCS o alguien que viene de uno de los VCS de la "vieja escuela", Mercurial parecerá más fácil.

Por ejemplo, agregar archivos, la inexistencia del índice en Hg, la facilidad de volver a algunas revisiones y ramificaciones antiguas desde allí (solo actualizar y confirmar) como algunos de los ejemplos más "obvios". Ahora, la mayoría de las características de un sistema se pueden emular en otro y viceversa, pero eso requiere cierto conocimiento en Git, mientras que en Mercurial los valores predeterminados (si me permite llamarlos así) son bastante "fáciles de usar". Esas pequeñas cosas: el cambio aquí y allá, el comportamiento no obvio en un comando y así sucesivamente ... estas cosas se suman, y al final, un sistema parece más fácil de usar que el otro.

Solo para completar la respuesta; Uso git, pero cuando recomiendo un VCS para alguien que es "nuevo para ellos", casi siempre recomiendo Mercurial. Recuerdo, cuando llegó por primera vez a mis manos, se sintió muy intuitivo. Según mi experiencia, Mercurial produce menos wtf / minuto que Git.

Torre
fuente
+1 para "menos peso / minuto" -1 para "esto es muy subjetivo". No es muy subjetivo ... No sé por qué la gente todavía piensa que las diferencias de IU son subjetivas. Si tomo mercurial y md5 hash sus comandos, no harías el argumento de que algunas personas podrían encontrar un md5 hash más intuitivo que el original, ¿verdad? (Espero que no). Lo mismo es cierto de Git. Git es solo más fácil que mercurial si tu experiencia con git es considerablemente más sustancial que mercurial.
weberc2
17

Creo que es tan simple como esto: Mercurial tiene una sintaxis más familiar (particularmente para usuarios de SVN) y está bastante bien documentada. Una vez que se acostumbre a la sintaxis de Git, lo encontrará tan fácil de usar como cualquier otra cosa.

pdr
fuente
77
No. Hay muchos más pasos de flujo de trabajo para que pueda llamarlo simplemente "sintaxis diferente". Debes comprender el modelo subyacente que estás manipulando y todo el estado del índice git para poder usar Git. Decir que SQL y Pascal son dos sintaxis diferentes para la misma cosa sería igualmente incorrecto. Git es un sistema de versiones de contenido de sistema de archivos con características DVCS. Mercurial es un DVCS que no realiza todas las operaciones de control de versiones del sistema de archivos GIT, solo el subconjunto que todos los usuarios de DVCS requieren.
Warren P
9

Las percepciones pueden estar cambiando con el tiempo, sobre esto. Mercurial está muy bien diseñado, al igual que Git. Mercurial parece ser más fácil de aprender (al menos lo fue para mí), y ha habido dificultades que encontré en Git, que no tengo paralelo en Mercurial. Traté de aprender Python y Ruby, y llegué más lejos, más rápido con Python. Eso no significa que Python sea siempre y en todas partes mejor que Ruby, o incluso que sea mejor para mí. Es justo lo que aprendí y con lo que me quedé. Los programadores a menudo hacen guerras santas por preferencia personal. Otros seres humanos hacen eso también.

Soy un usuario mercurial que trata de mantener una mente abierta sobre Git, y admito libremente que no se ha "convertido en mi nueva cosa favorita" en la misma medida que Mercurial. Sin embargo, creo que Git es realmente muy agradable.

Un contraejemplo para la complejidad GIT / mercurial: el soporte Nice GIT está integrado en XCode, en Mac. Menos fácil de usar XCode con Mercurial que GIT.

Mi experiencia con GIT hasta ahora ha sido que me confundo y me pierdo y necesito consultar más la documentación mientras la uso. Creo que se ha escrito mucha documentación, pero nada que me haya permitido "asimilarla". En segundo lugar, puedo modificar y extender Mercurial fácilmente en Python, y como soy experto en Python, y como cualquiera realmente podría aprender Python rápidamente, me parece una ventaja. También conozco C y escribo extensiones de Python en C, así que supongo que algún día, si necesito una, podría escribir fácilmente una extensión de Git en C.

La facilidad de uso no es algo fácil de cuantificar. Está allí, y no creo que sea completamente subjetivo, pero no tenemos buenas técnicas de medición objetiva. ¿Cuáles serían las unidades para facilitar su uso? ¿Milli-iPods?

No soy tan partidista como para ser 100% pro-mercurial y 100% anti-git. Ahora me siento más cómodo con Mercurial, en Windows y en Linux, y cuando empiece a hacer más trabajo con Mac, espero que intente seguir con XCode + GIT.

Actualización 2013: ahora he usado Mercurial Y GIT el tiempo suficiente para encontrar algunas características que desearía que tuviera Git, como esta pregunta sobre estrategias de fusión. Realmente Git es increíble, si es difícil de aprender, y a veces enloquecedoramente complejo.

Warren P
fuente
7

Hay algunas cosas que es probable que la OMI ponga a los nuevos usuarios fuera de Git:

  1. La cultura Git está más centrada en la línea de comandos. Si bien ambas herramientas tienden a enfocarse demasiado en la línea de comando (como he dicho varias veces, las instrucciones de la línea de comando pueden ser poderosas y más fluidas, pero no son una buena estrategia de marketing ) este es mucho más el caso con Git. Mientras que Mercurial tiene una herramienta GUI estándar de facto en TortoiseHg, que es incluso la opción de descarga predeterminada para los usuarios de Windows en la página de inicio de Mercurial, Git tiene varios front-end GUI competitivos (TortoiseGit, Extensiones Git, gitk, etc.) que no están bien publicitados en el sitio web de Git, y que de todos modos son una completa monstruosidad. (¿Texto negro en etiquetas rojas? ¡Vamos, TortoiseGit, puedes hacerlo mejor que eso!) También hay una actitud mucho más generalizada en la comunidad Git de que las personas que usan herramientas GUI no son desarrolladores de software adecuados.

  2. Git tiene varios valores predeterminados listos para usar que tienen mucho sentido para los usuarios avanzados, pero es probable que sean sorprendentes si no intimidan a los nuevos usuarios. Por ejemplo, es mucho más agresivo sobre la automatización de tareas como la fusión (por ejemplo, git pull se fusiona y confirma automáticamente cuando es posible). Hay un caso para las fusiones totalmente automatizadas , pero la mayoría de los usuarios inexpertos están aterrorizados de fusionarse, y necesitan tener la oportunidad de ganar confianza en sus herramientas antes de liberar todo su poder en su código fuente.

  3. Documentación y complejidad inherente:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    
jammycakes
fuente
3
En realidad, prefiero una ayuda de 912 líneas de largo a una ayuda de 64.
Dysaster
10
En realidad, prefiero una interfaz de usuario que sea tan intuitiva y perfecta que no necesites ayuda en primer lugar.
jammycakes
2
Quiero tanto la GUI como la ayuda. :) Lo que me parece intuitivo es un desastre para otra persona.
Dysaster 01 de
1
Claro, pero cuando la ayuda es necesaria, debería ser fácil de seguir.
jammycakes
3
He pensado en una nueva analogía; Git es como C ++ (¡lo siento, Linus!) Y Mercurial es como Pascal. Lo que está implícito y solo se puede hacer de una manera en Pascal (o Mercurial) se puede hacer explícitamente, diecinueve maneras diferentes en C ++ (y Git). Algunas personas prefieren herramientas eléctricas con más botones y palancas, y Git es eso.
Warren P
3

Una cosa que puedo pensar es

git add .
git commit -am "message"

vs.

hg ci -Am "message"

git commit -ano agrega archivos recién creados, hg ci -Alo que significa que algo que requiere dos comandos con git se puede hacer con un comando en Mercurial. Por otra parte, "escribir menos" no significa necesariamente "más fácil de usar".

Zhehao Mao
fuente
11
A menudo encuentro que en mi flujo de trabajo, agregar nuevos archivos automáticamente no es realmente deseable. He llegado a preferir cómo git commit -afunciona simplemente porque hace que sea más fácil controlar qué se agrega y qué no se agrega para una confirmación determinada. (En realidad, no es inusual para mí especificar nombres de ruta individuales para cada uno svn cipara evitar agregar material no relacionado a una confirmación.)
greyfade
3
Es justo, pero creo que hg cisin la -Abandera hace el equivalente de git commit -a. He usado git mucho más que hg, así que no estoy 100% seguro.
Zhehao Mao
Lo he comprobado, hg ci== git commit -a.
Zhehao Mao
pero si especifica archivos específicos con hg commit, puede evitar extraer los que no desea. En los casos poco frecuentes en los que quiero este control, encuentro que funciona bien.
Alex Miller
1
¿por qué "agregaría git"? y luego "git commit -am"? ¿No estaría todo ya agregado al índice?
jacobangel
3

Porque es.

Git expone mucho más de sus agallas que mercurial. Puedes usar mercurial felizmente a los pocos minutos de haberlo recogido, pero me parece muy difícil lidiar con git después de un par de meses de lucha (he hecho muy poco en los últimos meses aparte de tratar de aprender git). ) Estoy usando tanto desde la línea de comandos como sobre todo en Linux, así que esto no es solo una aversión a la interfaz de la línea de comandos.

Un ejemplo simple son los relativamente pocos indicadores y argumentos de línea de comando necesarios para mercurial en comparación con git. El área de preparación y el comportamiento del comando add en git también agrega más complejidad de la necesaria. El trío de reinicio, verificación y reversión y sus múltiples permutaciones agrega una enorme complejidad, lo cual era bastante innecesario cuando presenciaba la naturaleza directa de revertir y actualizar en mercurial.

Estoy de acuerdo con el comentario anterior también sobre Hginit , definitivamente hizo que Mercurial fuera mucho más fácil de comprender. Bien escrito y muy fácil de entender. Ninguna de la documentación escrita para git se acerca. Por mi parte, la mayoría de lo escrito por Scott Chacone (que ha escrito la mayor parte de la documentación / libros sobre git) es particularmente confuso.

revs haziz
fuente