¿Es posible enviar un file que desafíe el comportamiento de finalización de línea especificado por .gitattributes?

Si se .gitattributes un file .gitattributes al directory determinado, con exactamente el siguiente contenido:

 *.txt text 

¿Hay alguna forma posible de que un nuevo file o un file previamente normalizado (por ejemplo, todas las terminaciones de línea LF) se puedan comprometer con ese directory y no se normalicen? Es decir, ¿hay alguna manera posible de que las nuevas terminaciones de línea CRLF puedan introducirse en el repository después de habilitar .gitattributes con el modo de text especificado?

Para parafrasear nuevamente, ¿este file .gitattributes una forma absolutamente infalible para evitar que las nuevas líneas CRLF se comprometan con los files *.txt en el directory que contiene el file .gitattributes ? Quiero convencer a mis colegas de que el file .gitattributes es completamente suficiente, y que las medidas adicionales para excluir los CRLF (por ejemplo, un enlace del lado del server) son innecesarias.

Una respuesta debe confirmar que es imposible anular el comportamiento de final de línea especificado por .gitattributes , o proporcionar un contraejemplo explicando cómo se puede eludir el file .gitattributes y queuerse en algunas terminaciones de línea CRLF.

No es fácil a través de gitattributes , ya que los patrones negativos están prohibidos.

De hecho, en estos días (marzo de 2013) se está proponiendo un parche para el !pattern Make !pattern En .gitattributes no fatales .

Por lo tanto, debe colocar una regla global como *.txt solo en files .gitattributes presentes en subdirectorys en los que sabe que no necesitará CRLF.

Y reserve reglas de text más detalladas en .gitattributes presentes en directorys con contenido mixto.


kostmo menciona en los comentarios el error 421364 de EGit :

Hasta que esto se implemente, recomiendo esta configuration:

  1. Para cada proyecto de Eclipse, vaya a Properties > Resource y cambie " New text file line delimiter " a Other: Unix . .settings/org.eclipse.core.runtime.prefs files .settings/org.eclipse.core.runtime.prefs resultantes.
  2. No configure ningún .gitattributes o " core.autocrlf " para Git.
    Esto significa que los files tendrán las mismas terminaciones de línea en el directory de trabajo que en el repository. Git y EGit no convertirán ningún contenido de file.

Con 1., todos los files nuevos que se crean en Eclipse tendrán terminaciones de línea correctas ( LF ), incluso cuando los haya creado un usuario en Windows.

Para los files que ya están en su repository con CRLF , puede repararlos y confirmar el resultado. Recomiendo usar dos2unix o fromdos en la línea de command.

Nota: ese problema ( error 421364 ) acaba de ser recalificado como duplicado del error 342372 por Lars Vogel (25 de marzo de 2014).

Entonces, el soporte de .gitattributes por JGit está "asignado", pero su implementación es Todavía en progreso .

La implementación está siendo revisada (enero de 2015):

  • " review 1614 " Agregue soporte básico para .gitattributes

Clases principales para analizar y procesar files .gitattributes , incluido el soporte para leer attributes en WorkingTreeIterator y dirCacheIterator.

  • " review 35377 " Agrega el cálculo de los attributes de git en el treewalk

Agrega la function getAttributes al paseo por el tree.
El cálculo de attributes debe ser realizado por TreeWalk ya que necesita un WorkingTreeIterator y un DirCacheIterator .

Parafraseando nuevamente, este file .gitattributes es una manera absolutamente infalible

No. Git tiene muchas comodidades para hacer que las tareas habituales sean fáciles y poner a Speedbumps en el path de cosas cuestionables, pero no limitará su control sobre su propio repository.

Quiero convencer a mis colegas de que el file .gitattributes es completamente suficiente, y que las medidas adicionales para excluir los CRLF (por ejemplo, un enlace del lado del server) son innecesarias.

Ellos son necesarios. Nadie puede controlar lo que otros hacen en sus propios repositorys.

 git update-index --cacheinfo \ 100644,`git hash-object -w --no-filters path/to/file`,path/to/file 

De los documentos de hash git git

–Sin filters
Haga una pausa en el contenido tal como está, ignorando cualquier filter de input que haya elegido el mecanismo de attributes, incluida la conversión de fin de línea. Si el file se lee desde la input estándar, esto siempre está implícito, a less que se proporcione la opción –path.