Desactivar el área de configuración de git

Realmente no me gusta el área de preparación de git, simplemente hace que mi vida sea innecesariamente confusa.Desactivar el área de configuración de git

¿Es posible desactivarlo para que todos los archivos editados y nuevos estén en un único contexto? Entonces ese git diff muestra la diferencia entre el repositorio y mi directorio de trabajo (y no tengo que escribir también git diff --cached) y para que git ci compruebe toda mi copia de trabajo (no solo la parte que está en etapas).

Si no, las alternativas (como configurar cofiguraciones) para que parezca que no tengo una puesta en escena también serían geniales.

No tengo la opción de cambiar a un DVCS diferente y no quiero aprender a apreciar el área de preparación. Por favor, no publicar sugerir estos :(

Gracias, -Shawn

PS: He formulado esta en superuser.com, https://superuser.com/questions/192022/disable-git-staging-area, pero ese foro parece haber mucho menos publicado (sólo 118 GIT etiquetado en comparación con 4448 aquí)

Fuente

2010-09-30 sligocki

Nunca quitaría la puesta en escena incluso si fuera posible, pero te voté solo para ver si es posible. – matpie

Ser desarrollador se trata de aprender. Ni siquiera puedo imaginar por qué querrías ignorar tus herramientas y no aprender a usar sus mayores fortalezas. ¿También te opones a aprender nuevas API o nuevos patrones de diseño? :/ – Daenyth

@Daenyth: no tengo problemas para aprender nuevas herramientas. Entiendo que esta * podría * ser una opción útil para algunas personas en algún momento. Estoy bastante seguro de que en mi situación no es útil. Creo que es una tontería que git te obligue a usar ciertas tecnologías (como el área de preparación) en lugar de simplemente * permitir * que las uses. A veces necesitas un destornillador y algunas veces un martillo, pero me enojaría si mi destornillador tuviera un martillo en el que tuviera que navegar para poder desenroscar el pomo de la puerta. – sligocki

Se podía utilizar git commit -a para cometer todos los archivos modificados/eliminados. todavía habría que añadir los archivos sin seguimiento pensaron manualmente.

que vinieron de Subversion y estaba confundido por el área de ensayo en un primer momento también. Pero encontrarás que es muy útil. Si representas cambios que ha probado pero realice más cambios que rompen su compilación, puede restablecer nuevamente a sus cambios por etapas.

Fuente

2010-09-30 20:37:59 matpie

Sí, siempre uso git ci -a estos días, pero (desafortunadamente) no puedo establecer ci = commit -a en mi rc porque entonces no pude 'comprometer solo un archivo (a través de git ci foo) porque se queja de un choque entre - una lista de archivos explícita – sligocki

El área de preparación es (IMO) una de las mayores fortalezas de Git y realmente muestra cómo es diferente de cualquier otro DVCS que existe.

Puede utilizar

git commit -a

para agregar automáticamente los archivos modificados. Sin embargo, para archivos no rastreados usted está solo. Practica git add . && git commit.

Si no te gusta utiliza otro VCS. ¿Obligado a usar un repositorio git? Vea algunos de los complementos disponibles que son compatibles, como hg-git.

Personalmente me gustaría aprender a jugar a los puntos fuertes de git en lugar de luchar contra él. Imagine que se encuentra en medio de una gran sucursal desordenada, pero necesita realizar algunos cambios selectivos para la producción. Boom, git add [files] y luego confirmar y presionar. Vuelve al trabajo sin ensuciar nada más. Hay innumerables otros ejemplos, pero tal vez sea el más fácil de entender.

Fuente

2010-09-30 20:38:50

No es una opción para usar otro. Estoy atrapado con esta herramienta. – sligocki

@sligocki: Puedes usar varias opciones en lugar de git para emular un repositorio de git. Ver [hg-git] (http://hg-git.github.com/). –

no, no puedo. ¡Estoy realmente cansado de que la gente diga esto! Estoy usando herramientas que están construidas sobre git, no tengo la opción de usar otro DVCS o estas herramientas no funcionarán y la ventaja completa de usar un DVCS en primer lugar habría desaparecido. – sligocki

No. Aprendes a amarlo.

En una nota más seria, git add -A; git commit es probablemente tu amigo. De esta forma, evita la mayoría de las interacciones con (y los beneficios de) el área de ensayo.

git add -A es más poderoso que el git commit -a habitual. Encontrará nuevos archivos, además de organizar contenido modificado y eliminar archivos que ya no están en el árbol de trabajo.

Fuente

2010-09-30 20:38:51

¿Por qué deberíamos aprender a amarlo si es posible automatizar todos esos procedimientos de estadificación manual? –

@VitaliPom Porque es realmente útil, por supuesto. –

Es puramente una cuestión de opinión que "aprendes a amarlo". El área de ensayo simplemente se interpone en el camino de mis casos de uso normales. –

Los alias son tus amigos.

Por ejemplo, puede crear un comando diff que hace lo que quiere con la tipificación mínima: en su .gitconfig poner

[alias] 
     di = diff HEAD 
     co = commit -a

continuación, puede simplemente hacer git di y obtener su propio diff, o git co y obtener su propio comando de compromiso personal.

Fuente

2010-09-30 20:59:13 EOL

pero luego git di no me mostrará lo que está en mi directorio de trabajo, quiero que git diff me muestre el cambio que se confirmará cuando confirme -a. – sligocki

Además, no puedo establecer co = commit -a en mi rc porque entonces no pude confirmar un solo archivo (a través de git ci foo) porque se queja de un choque entre -a y la lista de archivos explícita. – sligocki

@sligocki: Cambié el alias para que 'git di' te brinde lo que indicaste en tu primer comentario. En cuanto a tu segundo comentario: puedes enviar un único archivo con el habitual 'git commit foo'. – EOL

y no quiero aprender a apreciar el área de preparación. Por favor, no enviar a sugerir estos :(

Al igual que todos los demás. Yo voy a sugerir a aprender a como el área de preparación. Realmente es útil a pesar de que el 90% de las veces se le ignóralo.

Si actualmente no lo encuentras útil, creo que estás pensando en cometer errores. Todavía estás pensando en términos de archivos individuales o de todo al mismo tiempo. La forma correcta de pensar en commits es por función/corrección y las características/soluciones a menudo se distribuyen en más de un archivo. Debe agrupar los cambios relacionados en una única confirmación. Y a veces ese grupo de cambios no abarca todos los cambios actuales. útil.

Sé que esto no es lo que quieres escuchar, pero realmente, el momento en que dejas de luchar contra la herramienta y aprendes a vivir con ella es cuando deja de ser "doloroso" usar la herramienta.

Fuente

2010-09-30 21:02:04 slebetman

Gracias slebetman, entiendo por qué el área de preparación podría ser útil. En este momento, no es realmente doloroso, solo hace las cosas más complicadas, de vez en cuando voy a ejecutar git diff y me confundo por qué algunos de los archivos no están allí. En mi situación, en realidad estoy empujando de git a un repo forzado, por lo que las revisiones de git son solo para mí y pueden ser mucho más crudas. Por lo tanto, no creo que quiera crear el historial de revisiones, solo utilícelo para volver a un estado que ya funcionaba o probar nuevas rutas de desarrollo. – sligocki

En lugar de hacer eso, intente hacer los cambios en su lugar y luego use git diff solo para ver "Ok, ¿qué tengo que agregar a la confirmación actual?". Si ve que la diferencia es lo que desea agregar, agréguelo. De lo contrario, elimínelo o ignórelo. Continúa trabajando hasta que git diff no muestre cambios, entonces estarás listo para confirmar tus cambios. – Arafangion

Desactivar el área de configuración de git

Respuesta

Cuestiones relacionadas