¿Equivalentes Git de los comandos Mercurial más comunes?

He estado usando Mercurial pero me gustaría hacer una demostración rápida de Git.

¿Cuáles son los equivalentes de Git de:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

La piedra rosetta de Git-HG no está mal

Hay algunas otras trampas entre los dos que no se mencionan allí. Esta lista fue tomada de mi propia publicación de blog cuando fui por el otro lado (git -> hg).

Hg .hgignore , syntax: glob tiene el mismo comportamiento que .gitignore de git.

Git .git/config , ~/.gitconfig, el uso git-config para modificar los valores de
Hg .hg/hgrc , ~/.hgrc, el usohg help -c config

Git git commit -v<br> Hg hg diff | less; hg commit

Git gitk<br> Hg hg view, or thg from [TortoiseHg][1]

Git git gui<br> Hg Mercurial no incluye GUI para seleccionar conjuntos de cambios, solo hg recordcomando de consola .

Git git rebase<br> Hg hg rebase . Porque git rebase --interactivehay hg histedit , o Mercurial Queues

Git git push URL ; git remote add origin URL<br> Hg hg push URL; $EDITOR .hg/hgrc ; [paths] default = URL

Git gitk, git log origin/master..HEAD<br> Hg hg outgoing

Git git format-patch RANGE<br> Hg hg email -m filename -o

Git git add . ; Tenga en cuenta el punto
Hg hg add ; No se necesita ningún punto.

Git git checkout REVISION-KEY<br> Hg hg update CHANGESET

Solo para llenar los espacios en blanco, algunos de los comandos más útiles de Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Sin equivalente real. Solo puedes hacer el equivalente dehg pull; hg log -r .:

Hg hg out URL
Git Por favor agregue si sabe cómo.

Para la resolución de conflictos de fusión, el hg resolvecomando en Mercurial tiene algunas opciones que cambian el comportamiento:

Hg hg resolve -m FILE (marca el archivo como resuelto solucionando manualmente el problema del conflicto)
Git git add FILE

Hg hg resolve -u FILE marca el archivo como no resuelto.
Git git reset HEAD FILE para quitar la etapa del archivo.

Hg hg resolve -l (enumera archivos con conflictos resueltos / no resueltos)
Git git status : los archivos que se fusionaron limpiamente se agregan al índice automáticamente, los que no tienen conflictos

Hg hg resolve FILE (después de una fusión, intenta volver a fusionar el archivo)
Git no tiene equivalente para volver a fusionar que yo sepa.

Nota: una de las mayores diferencias entre Git y Mercurial es la presencia explícita del índice o área de preparación .

Desde Mercurial para usuarios de Git :

Git es el único DistributedSCM que expone el concepto de índice o área de ensayo. Los demás pueden implementarlo y ocultarlo, pero en ningún otro caso el usuario lo sabe ni tiene que lidiar con él.

El equivalente aproximado de Mercurial es el DirState, que controla la información del estado de la copia de trabajo para determinar los archivos que se incluirán en la próxima confirmación. Pero en cualquier caso, este archivo se maneja automáticamente.
Además, es posible ser más selectivo en el momento de la confirmación, ya sea especificando los archivos que desea confirmar en la línea de comandos o utilizando la extensión RecordExtension.

Si se sintió incómodo tratando con el índice, está cambiando para mejor ;-)

El truco es que realmente necesitas comprender el índice para explotar completamente Git. Como nos recuerda entonces este artículo de mayo de 2006 (y sigue siendo cierto ahora):

"Si niega el índice, realmente niega el git".

Ahora, ese artículo contiene muchos comandos que ahora son más simples de usar (así que no confíe demasiado en su contenido;)), pero la idea general sigue siendo:

Está trabajando en una nueva función y comienza a realizar pequeñas modificaciones en un archivo.

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

En este punto, su próxima confirmación embarcará 2 modificaciones menores en la rama actual

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Solo registra los cambios agregados al área de preparación (índice) en este punto, no los cambios principales actualmente visibles en su directorio de trabajo.

$ git branch newFeature_Branch
$ git add myFile

La próxima confirmación registrará todos los demás cambios importantes en la nueva rama 'newFrature_Branch'.

Ahora, agregar interactivamente o incluso dividir una confirmación son características disponibles con Mercurial, a través del hg recordcomando ' ' u otras extensiones: necesitará instalar RecordExtension, o el CrecordExtension.
Pero esto no es parte del flujo de trabajo normal de Mercurial.

Git ve una confirmación como una serie de " cambios en el contenido del archivo " y le permite agregar esos cambios uno a la vez.
Debería estudiar esa característica y sus consecuencias: la mayor parte del poder de Git (como la capacidad de revertir fácilmente una fusión (o dividir el problema en dos o revertir una confirmación) , al contrario de Mercurial ) proviene de ese paradigma de "contenido de archivo".

tonfa (en en el perfil: "Hg dev, pythonist": cifras ...) intervino, en los comentarios:

No hay nada fundamentalmente "git-ish" en el índice, hg podría usar un índice si se considerara valioso, de hecho mqo shelveya forma parte de eso.

Oh chico. Aquí vamos de nuevo.

Primero, no estoy aquí para hacer que una herramienta se vea mejor que otra. Encuentro a Hg genial, muy intuitivo, con un buen soporte (especialmente en Windows, mi plataforma principal, aunque también trabajo en Linux y Solaris8 o 10).

El índice es en realidad frontal y central en la forma en que Linus Torvalds trabaja con un VCS :

Git usó actualizaciones de índice explícitas desde el día 1, incluso antes de realizar la primera fusión. Es simplemente como siempre he trabajado. Tiendo a tener árboles sucios, con algún parche aleatorio en mi árbol que no quiero comprometer, porque es solo una actualización de Makefile para la próxima versión

Ahora, la combinación del índice (que no es una noción que se ve solo en Git) y el paradigma "el contenido es el rey" lo hace bastante único y "git-ish" :

git es un rastreador de contenido y un nombre de archivo no tiene significado a menos que esté asociado a su contenido. Por lo tanto, el único comportamiento sensato para git add filename es agregar el contenido del archivo y su nombre al índice.

Nota: el "contenido", aquí, se define de la siguiente manera :

El índice de Git se define básicamente como

• suficiente para contener el " contenido " total del árbol (y esto incluye todos los metadatos: el nombre del archivo, el modo y el contenido del archivo son partes del "contenido", ¡y no tienen sentido por sí mismos! )
• información adicional "estadística" para permitir las obvias y triviales (¡pero muy importantes!) optimizaciones de comparación del sistema de archivos.

Lo que realmente debe ver el índice como siendo el contenido .

El contenido no es el "nombre del archivo" ni el "contenido del archivo" como partes separadas. Realmente no puedes separar los dos .
Los nombres de archivo por sí solos no tienen sentido (también tienen que tener contenido de archivo), y el contenido de archivo por sí solo es igualmente insensato (tienes que saber cómo llegar a él).

Lo que estoy tratando de decir es que git fundamentalmente no te permite ver un nombre de archivo sin su contenido. Toda la noción es una locura y no es válida. No tiene relevancia para la "realidad".

De las preguntas frecuentes , las principales ventajas son:

• comprometerse con una fina granularidad
• ayudarlo a mantener una modificación no comprometida en su árbol durante un tiempo razonablemente largo
• realice varios pasos pequeños para una confirmación, verificando lo que hizo git diffy validando cada paso pequeño con git addo git add -u.
• permite una excelente gestión de conflictos de fusión: git diff --base, git diff --ours, git diff --theirs.
• permite git commit --amendmodificar solo el mensaje de registro si el índice no se ha modificado mientras tanto

Personalmente, creo que este comportamiento no debería ser el predeterminado, desea que las personas cometan algo que se prueba o al menos se compila

Si bien tiene razón en general (sobre la parte "probado o compilado"), la forma en que Git le permite bifurcar y fusionar (seleccionar o reajustar) le permite comprometerse con la frecuencia que desee en una rama privada temporal (solo empujada al repositorio de "copia de seguridad" remoto), mientras se vuelven a hacer esas "confirmaciones feas" en una rama pública, con todas las pruebas adecuadas en su lugar.

Mercurial:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

Equivalentes de Git:

git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status

Es más o menos lo mismo, sin addremove:

git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes

Sin embargo, estos son comandos que usaría cuando trabaja solo. Se entra en la ordenada cosas cuando se quiere fusionar sus cambios con el trabajo de otras personas con git pully git push, y los comandos relacionados.