Cómo obligar a los usuarios a usar la dirección de correo electrónico en minúsculas en GIT

Estoy buscando posibilidades para confirmar si la dirección de correo electrónico del committer es minúscula para evitar problemas como este .

Estoy pensando en implementar una secuencia de commands de enlace de precompilation del lado del cliente que convertiría la mayúscula en minúsculas en el nombre de usuario y el correo electrónico, o simplemente advierte al usuario que debe cambiar en la configuration de git.

No quiero escribir algo como esto cada vez que encuentro errores durante la import. Esto no es recomendable, ya que da como resultado una modificación en los valores de ref y puede romper algunos contenidos.

$ git filter-branch --env-filter 'export GIT_AUTHOR_EMAIL="yourname@example.com";GIT_AUTHOR_NAME="Yourname"' 

Por favor sugiérame si hay otras forms mejores de lograr lo mismo.

Los ganchos del lado del cliente no son fiables IMO (el cliente siempre puede pasar –no-verify, o simplemente eliminar el gancho por completo). Te conviene usar un gancho del lado del server que rechace los posts que se hayan confirmado con direcciones de correo electrónico incorrectas, y luego imprimir instrucciones de recuperación para el usuario final sobre cómo rehacer sus confirmaciones con las direcciones de correo electrónico adecuadas.

Si tiene confirmaciones existentes en el historial publicado, no tiene opciones no destructivas para corregirlas.

-UN

Esta es una muestra muy aproximada que solo maneja correctamente una actualización de twig existente. Necesitará agregar muchos más casos para manejar nuevas sucursales, eliminaciones, tags, etc., así como instrucciones sobre cómo pueden configurar su correo electrónico y cómo recrear las confirmaciones con la información correcta de correo electrónico. Pero debería ayudarte a comenzar.

.git / hooks / update

 refname="$1" oldrev="$2" newrev="$3" for sha in $(git rev-list ${oldrev}..${newrev}) do git log ${sha} --format="%ae %ce" -1 | grep [AZ] if [ $? -eq 0 ] then echo "SHA ${sha} contains an illegal email address containing uppercase characters" git log ${sha} --format="%ae %ce" -1 exit 1 fi done 

Si intentas empujar un SHA obtendrás algo como esto

remoto: SHA 49511d51548720f774b4a2bed113c43d06c32a34 contiene una dirección de correo electrónico ilegal que contiene caracteres en mayúsculas remotos: AndrewC@whoops.com remote: error: hook declinado actualizar los refs / heads / master To / scratch / email_repo! [remoto rechazado] maestro -> maestro (gancho rechazado)

No estoy seguro de si está fuera de tema, pero ¿por qué tiene que obligar a los usuarios a usar el correo electrónico en minúsculas? La parte local (parte antes @) de la dirección de correo electrónico puede distinguir entre mayúsculas y minúsculas.

Jeyanthan@serverA.com y JEYANTHAN@serverA.com pueden ser una dirección de correo electrónico diferente y todo depende de serverA.com.

Ver RFC

Los verbos y valores de argumento (por ejemplo, "A:" o "a:" en el command RCPT y palabras key de nombre de extensión) no distinguen entre mayúsculas y minúsculas, con la única exception en esta especificación de una parte local de buzón (las extensiones SMTP pueden especificar caso elementos sensibles). Es decir, un verbo de command, un valor de argumento que no sea una parte local de buzón y text de forma libre PUEDEN estar codificados en mayúsculas, minúsculas o cualquier combinación de mayúsculas y minúsculas sin afectar su significado. La parte local de un buzón DEBE SER tratada como sensible a mayúsculas y minúsculas.

http://tools.ietf.org/html/rfc5321#section-2.4

http://en.wikipedia.org/wiki/Email_address#Common_local-part_semantics

Si encuentra algún problema al importar una dirección de correo electrónico en mayúscula, creo que NO debe abordar este problema en git, sino que debe estar en ese progtwig de import.

¿Ha considerado abordar esto en la entrega del código y la revisión por pares?

Por ejemplo, puede adoptar una práctica donde las nuevas entregas se realizan en una twig de feature y solo una vez que se completan (y revisan) se fusionan en una twig de integration . Como parte de la revisión del código, puede solicitar que la (s) persona (s) que realiza la revisión verifiquen el historial de confirmaciones, al cambiar a la twig de características, para

  1. user.email apropiado. user.email
  2. user.name adecuado
  3. Mensajes de compromiso significativos
  4. Aplastado se compromete para cambios similares

Este enfoque requiere disciplina, pero el resultado arrojaría una twig de integration "limpia" en la que no tendría que ejecutar git filter-branch todo el time.

Si está utilizando Github, y tiene bifurcaciones y requestes de extracción en la image, lo mismo se puede hacer, pero tendría que hacerse antes de que alguien presione el button verde "fusionar esto".

Para ser brutalmente honesto, tienes un problema con las personas, no un problema tecnológico. El verdadero problema es que las personas no son conscientes o no les importa.

Cualquier persona con acceso de escritura al repos debe ser informado y asistido. Si está tratando con terceros, niegue las requestes de extracción si no cumplen con los estándares.

mygit una function mygit (o el nombre que quieras) como envoltorio para el git normal.

Esto, por ejemplo, verifica cada argumento que se da. En caso de que contengan cualquier carácter diferente de un dígito, una minúscula o una @, muestra un error y se cierra. De lo contrario, el command git se ejecuta normalmente.

 mygit () { for var in "$@" do echo "arg is: $var" if [[ "$var" =~ [^0-9a-z@] ]]; then echo "argument $var has characters not being 0-9, az or @" return fi done git $@ } 

Para usarlo permanentemente, guárdalo en tu file ~/.bashrc . Incluso puedes hacer que git se comporte como mygit hace mygit . Solo necesita establecer un alias: alias git=mygit o cambiar la function para que se llame git .

Intereting Posts