Git: Cómo listr todos los files (en etapas) que intentan ser comprometidos

Escribió una secuencia de commands bash para el gancho de preparar-comprometer-msg git. Enumera todos los files por etapas que existen, pero solo quiero los files por etapas que se intentan comprometer (es decir, el ejemplo de la input / salida deseada en la parte inferior de la página).

El trabajo de mi secuencia de commands es evitar que se produzca una confirmación si los files que intentan comprometerse no siguen una cierta convención de comentarios (es decir, piense en documentos java). No solo esto, sino que edita y formatea automáticamente los comentarios para cumplir con mi convención de comentarios. Esto es muy importante tener en count porque no puedo tomar el SHA-1 de la confirmación porque este script debe suceder antes de que se cree esa key.

Esto funciona perfectamente cuando ejecuto commit -a (es decir, commit all files). Sin embargo, me encuentro con problemas cuando quiero simplemente comprometer algunos de mis files en etapas.

¿Hay alguna manera de que pueda capturar solo los files por etapas que están intentando comprometerse, no solo cada file en etapas que existe?

Por ejemplo, digamos que mis files en etapas fueron los siguientes:

 file1.txt file2.txt file3.txt file4.txt file5.txt 

Cuando ejecuto git commit file1.txt file2.txt file3.txt , quiero capturar file1.txt file2.txt file3.txt en mi script … pero no file4.txt y file5.txt .

¿Hay alguna forma de hacer esto?

EDITAR: Definitivamente no es un duplicado. La solución a la pregunta "duplicada" definitivamente no es lo que estoy pidiendo.

Git confirma operación, estado y control

Git introduce su propia terminología. Algunas de estas palabras han sido utilizadas de forma incorrecta, describiré los conceptos incomprendidos y los commands problemáticos que conducen a la formulación errónea.

Afortunadamente, git tiene un lenguaje muy fuerte y definido, donde cada término tiene un significado exacto, algunos de ellos se pueden ver en git help gitglossary . Para comprender los conceptos que usa git, vale la pena leer la página de git help git 5-50 veces junto con las páginas introductorias que están vinculadas desde allí.

Si instaló una versión de Git sin la documentation, abofetee al administrador del sistema. Supongo que la mayoría de las personas que leen activamente preguntas, respuestas y artículos son sus propios administradores, así que abofetee, pero no demasiado;) Por supuesto, los documentos se pueden encontrar en la networking, pero son parte integral de un trabajo … be-used git installation.

Afortunadamente, Git se inició y su núcleo fue escrito por una de las mentes más excelentes de nuestros días o, al less, por alguien que utiliza los conceptos lógicos más estrictos, en lugar de aplicar herramientas asesinas, para escribir y controlar su desarrollo de software: Linus Thorvalds.

Eso hace posible usar los mismos términos con significados definidos, cuando hablamos de git y operaciones en un repository de git. No voy a profundizar, ya que algunos de los conceptos se desarrollan con términos teóricos bastante avanzados en computación en mente.

El repository git

Hay dos types principales de repositorys git, llamados bare y non-bare , o a veces digo check-out ( git help init ). En este artículo, solo hablo sobre repositorys no desnudos, donde los files rastreados del repository viven en el directory de trabajo

de gitglossary (7):

  working tree The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit's tree, plus any local changes that you have made but not yet committed. 

Nota para los Noobs: gitglossary(7) significa la página del manual con el nombre "gitglossary" en la sección 7. Con el man se puede llegar a esta página con man -s7 gitglossary . Con git help gitglossary se git help gitglossary exactamente lo mismo, con la git help --web gitglossary usted ve un documento bien formateado en su browser, si su sistema está configurado para llamar remotamente a una página html en su session de browser. Con Windows, donde no hay nadie, siempre se lo dirigirá al browser. Para los commands de git, como agregar, la página del manual es man 1 git-add o git-add(1) .

Archivos rastreados

Hemos visto aquí, que el término rastreado significa que el repository de git conoce y controla ese file. El glosario no viene del gitglossary(7) , sino de la opción git-add(1)

  -u, --update Update the index just where it already has an entry matching <pathspec>. This removes as well as modifies index entries to match the working tree, but adds no new files. If no <pathspec> is given when -u option is used, all tracked files in the entire working tree are updated (old versions of Git used to limit the update to the current directory and its subdirectories). 

El command git add – update es una de las operaciones más importantes para entender el event handling git en el tree de trabajo.

Aquí muestra el problema

con git commit file1.txt file2.txt file4.txt , pero primero definamos algunos términos más.

Archivos por etapas o índice

El set de files montados crea el index (ver gitglossary (7) para el index , pero ignora los varios niveles de combinación o el índice no expandido ). Para nuestro propósito

The index is a stonetworking version of your working tree.

es decir, la versión almacenada de su tree de trabajo que está preparado para comprometerse como una commit (nuevamente gitgloassary (7)

commit `Como sustantivo: Un solo punto en la historia de Git;

… "revisión" o "versión" son sinónimos de otros sistemas de control de versiones. Como usuarios de Git decimos "commit".

… continuará (26.Viernes) …

 $ git status -s -uno ME AR 

El file E se modifica, el file R se organiza (se agrega).

Un file sin grabar tiene el marcador de acción en la segunda columna (después de que git reset E , para dejar de grabar el file E):

 $ git status -s -uno ME AR 

Estos pueden soltarse con grep -v '^ ' por ejemplo.

Aquí hay una testing completa en mi directory de testing:

Archivos rastreados

  ~/test/ed $ git ls-tree HEAD 100644 blob 96bf192a9be8d1cecc314f66bb1ef5961564e983 E 100644 blob 11470e37f3d22a2548ce5c85040a44c9581d7727 I 100644 blob 8f2f9e95d9b00595d1588ccef91495c06295f5fa O 

Archivos del sistema de files (todos, como en git commit -a )

  ~/test/ed $ ls -l . total 16 -rw-r--r-- 1 ingo ingo 140 25. Jun 05:48 E -rw-r--r-- 1 ingo ingo 143 25. Jun 05:39 I -rw-r--r-- 1 ingo ingo 106 25. Jun 05:29 O -rw-r--r-- 1 ingo ingo 157 25. Jun 05:28 R 

Estado del directory de trabajo: Cambios contra HEAD y files escalonados

  ~/test/ed $ git status -s -uno ME AR 

La salida sin los files modificados que aún no están o no más (reinicio de git) en el índice (también conocido como no configurado o no)

  ~/test/ed $ git status -s -uno|grep -v '^ ' AR 

Nombres de files en etapas solamente, sin la bandera de operación

  ~/test/ed $ git status -s -uno|grep -v '^ '|awk '{print $2}' R