Distribución de la configuración de git con el código

Question

Al tratar de estandarizar la plataforma para los desarrolladores, una de mis necesidades sería confirmar el .git/config para que todos tengan la misma configuración CRLF sin olvidar configurarlo manualmente.

¿Cómo configuro esto?

Estoy un poco preocupado por toda esta negatividad contra autocrlf. ¿Por qué no eliminar esta característica si no funciona? O los creadores de esta función son malentendidos o hicieron un experimento fallido con ella y debería eliminarse para evitar que más personas pierdan el tiempo (leyendo la página del hombre oscuro, haciendo preguntas, personas respondiendo esas preguntas, etc.).

Answer 1

siempre he encontrado la propiedad autocrlf config problemática. (como se expresa en mi respuesta Git 1.6.4 beta on Windows (msysgit) - Unix or DOS line termination)

• que no sólo hacen some merges tricky
• puede variar depending on the shell used within one environment
• también tiene problema con git status
• y con svn import.

Nota: msysgit issue 538 para establecerlo en true (que es el valor predeterminado establecido por el instalador msysgit), pero no estoy seguro.

yo preferiría una de las tres siguientes soluciones para:

• la configuración de un estilo de fin de línea
• haciendo que la configuración de propagarse a través de los diferentes pases de Git

1. Uso el nuevo config setting core.eol (1.7.2+)

Establece el tipo de fin de línea para usar i n el directorio de trabajo para los archivos que tienen establecida la propiedad de texto.
Las alternativas son 'lf', 'crlf' y 'native', que usa la terminación de línea nativa de la plataforma.
El valor predeterminado es nativo.

2. a checkout/checking .gitattribute. Ver gitattributes página del manual: crlf o core.autocrlf es la forma de registrar en un archivo .gitattributes lo que anteriormente era un atributo de configuración local.

3.un git attribute filter driver que puede:

• cumplir cualquier tipo de estándar de formato es posible que desee establecer
• aplicar esas normas a ciertos archivos/directorios
• ser registrado como un archivo de configuración (.gitattributes) capaz de ser empujado en cualquier parte .

Answer 2

Si está utilizando un sistema operativo de la familia Unix, le recomendaría simplemente crear un enlace simbólico.

ln -s .git/config git-config 
git add git-config 
git commit -m "Now tracking git config file" 

Answer 3

puede haber una manera mejor utilizar el hardlink:

En * nix o el sistema OS X:

ln .git/config git-config 
git add git-config 
git commit -m "Now tracking git config file" 

En Windows en el sistema NTFS sistema de archivos:

mklink /H git-config .git\config 
git add git-config 
git commit -m "Now tracking git config file" 

Pero debemos recordar que cuando se clona el proyecto para aplicar la configuración para realizar el procedimiento inverso:

En * nix o sistema OS X:

git clone FROM_PROJ_URL 
rm .git/config 
ln git-config .git\config 

En Windows en el sistema NTFS sistema de archivos:

git clone FROM_PROJ_URL 
del .git\config 
mklink /H .git\config git-config 

Answer 4

El .git/config Se pueden anular localmente por ~/.gitconfig.

Por lo tanto, como parte del script de compilación, Makefile o provision, puede proponer el cambio a los usuarios en su ~/.gitconfig, o cargar el script local .gitconfig a través del git config.

Por ejemplo, crear nuevos .gitconfig con algunos ajustes, y cargarlo por:

git config --local include.path "/path/to/.gitconfig" 

o pedir a los usuarios a tener en sus ~/.gitconfig estas líneas:

[include] 
    path = .gitconfig 

Si está utilizando Vagrant como parte de su distribución de código, puede cargar git config desde Vagrantfile por:

system('GIT_TRACE=1 git config --local include.path "$(git rev-parse --show-toplevel)/git/gitconfig"'); 

luego confirme su configuración de git en git/gitconfig, de modo que cada vez que los usuarios ejecuten el aprovisionamiento de su VM, este archivo se cargará automáticamente para su git en el equipo host (p. Ej. para exigir que core.filemode se deshabilite, por lo que Windows no tendrá ningún problema con los permisos de archivos).

---

Para forzar los finales de línea para los usuarios, debe utilizar .gitattributes lugar que debe trabajar fuera de la caja. Sintaxis de ejemplo para utilizar los finales de línea Unix (LF):

# Drupal git normalization 
# @see https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html 
# @see https://www.drupal.org/node/1542048 

# Define text file attributes. 
# - Treat them as text. 
# - Ensure no CRLF line-endings, neither on checkout nor on checkin. 
# - Detect whitespace errors. 
# - Exposed by default in `git diff --color` on the CLI. 
# - Validate with `git diff --check`. 
# - Deny applying with `git apply --whitespace=error-all`. 
# - Fix automatically with `git apply --whitespace=fix`. 

*.css  text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 
*.html text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 diff=html 
*.js  text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 
*.json text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 

# Auto-detect text files, ensure they use LF. 
*   text=auto eol=lf 

# Define binary file attributes. 
# - Do not treat them as text. 
# - Include binary diff in patches instead of "binary files differ." 
*.gz  -text diff