En caso de que esté entrando en esto en este momento, he pasado por esto hoy y puedo resumir dónde está esto. Si aún no lo has intentado, algunos detalles aquí pueden ayudarte.
Creo que el enfoque de @Omid Ariyan es la mejor manera. Agregue los scripts de precompilación y postpago. NO olvide nombrarlos exactamente como lo hace Omid y NO olvide hacerlos ejecutables. Si olvida alguno de estos, no tienen ningún efecto y ejecuta "git commit" una y otra vez preguntándose por qué no sucede nada :) Además, si corta y pega fuera del navegador web, tenga cuidado de que las comillas y los tics no sean correctos. alterado
Si ejecuta el script de precompilación una vez (ejecutando una confirmación de git), se crearán las licencias del archivo. Puede agregarlo al repositorio y creo que es innecesario agregarlo una y otra vez al final del script precompromiso. Pero no duele, creo (esperanza).
Hay algunos pequeños problemas sobre el nombre del directorio y la existencia de espacios en los nombres de los archivos en los scripts de Omid. Los espacios eran un problema aquí y tuve algunos problemas con el arreglo IFS. Para el registro, esta pre-commit guión ha funcionado correctamente para mí:
#!/bin/bash
SELF_DIR=`git rev-parse --show-toplevel`
DATABASE=$SELF_DIR/.permissions
# Clear the permissions database file
> $DATABASE
echo -n "Backing-up file permissions..."
IFSold=$IFS
IFS=$'\n'
for FILE in `git ls-files`
do
# Save the permissions of all the files in the index
echo $FILE";"`stat -c "%a;%U;%G" $FILE` >> $DATABASE
done
IFS=${IFSold}
# Add the permissions database file to the index
git add $DATABASE
echo "OK"
Ahora, lo que vamos a salir de esta?
El archivo .permissions está en el nivel superior del git repo. Cuenta con una línea por cada archivo, aquí está la parte superior de mi ejemplo:
$ cat .permissions
.gitignore;660;pauljohn;pauljohn
05.WhatToReport/05.WhatToReport.doc;664;pauljohn;pauljohn
05.WhatToReport/05.WhatToReport.pdf;664;pauljohn;pauljohn
Como se puede ver, tenemos
filepath;perms;owner;group
En los comentarios sobre este enfoque, uno de los carteles se queja de que se solo funciona con el mismo nombre de usuario, y eso es técnicamente cierto, pero es muy fácil solucionarlo. Tenga en cuenta el script de post-pago y envío tiene 2 piezas de acción,
# Set the file permissions
chmod $PERMISSIONS $FILE
# Set the file owner and groups
chown $USER:$GROUP $FILE
Así que sólo estoy manteniendo la primera, eso es todo lo que necesito. Mi nombre de usuario en el servidor web es realmente diferente, pero lo más importante es que no puede ejecutar chown a menos que sea root. Puede ejecutar "chgrp", sin embargo. Es bastante claro cómo poner eso en uso.
En la primera respuesta en esta publicación, la que es más ampliamente aceptada, la sugerencia es usar git-cache-meta, una secuencia de comandos que está haciendo el mismo trabajo que los scripts pre y post aquí están haciendo (salida de análisis desde git ls-files). Estos guiones son más fáciles de entender, el código git-cache-meta es bastante más elaborado. Es posible mantener git-cache-meta en la ruta y escribir scripts de pre-commit y post-checkout que lo usarían.
Los espacios en los nombres de los archivos son un problema con los dos scripts de Omid. En el script de post-pago y envío, usted sabe que tiene los espacios en los nombres de archivo si ve errores como éste
$ git checkout -- upload.sh
Restoring file permissions...chmod: cannot access '04.StartingValuesInLISREL/Open': No such file or directory
chmod: cannot access 'Notebook.onetoc2': No such file or directory
chown: cannot access '04.StartingValuesInLISREL/Open': No such file or directory
chown: cannot access 'Notebook.onetoc2': No such file or directory
Estoy comprobando en las soluciones para ello. Esto es algo que parece funcionar, pero sólo lo he probado en un caso
#!/bin/bash
SELF_DIR=`git rev-parse --show-toplevel`
DATABASE=$SELF_DIR/.permissions
echo -n "Restoring file permissions..."
IFSold=${IFS}
IFS=$
while read -r LINE || [[ -n "$LINE" ]];
do
FILE=`echo $LINE | cut -d ";" -f 1`
PERMISSIONS=`echo $LINE | cut -d ";" -f 2`
USER=`echo $LINE | cut -d ";" -f 3`
GROUP=`echo $LINE | cut -d ";" -f 4`
# Set the file permissions
chmod $PERMISSIONS $FILE
# Set the file owner and groups
chown $USER:$GROUP $FILE
done < $DATABASE
IFS=${IFSold}
echo "OK"
exit 0
Dado que la información de permisos es una línea a la vez, me puse IFS a $, por lo que sólo los saltos de línea son vistos como cosas nuevas.
He leído que es MUY IMPORTANTE volver a establecer la variable de entorno IFS como estaba. Puede ver por qué una sesión de shell puede salir mal si deja $ como el único separador.
posible duplicado de [GIT - cómo recuperar el git permisos de archivos piensa que el archivo debe ser?] (Http://stackoverflow.com/questions/2517339/git-how-to-recover- the-file-permissions-git-thinks-the-file-should-be) – kennytm
Sí, supongo que, aunque la solución que señalan, francamente no estoy seguro de qué hacer. Esperaba un enfoque más directo. – Yarin
¿Qué pasa con la situación en la que el código fuente proviene del entorno Dev (por ejemplo, Windows - XAMPP, etc.) que no tiene información sobre la propiedad del archivo? Los archivos al final del proceso de git deben coincidir con la propiedad y los permisos para la ubicación de destino. ¿Puede git-cache-meta lidiar con esto? De acuerdo con Yarin ... seguramente este es un buen caso de uso general, que debería tener una solución bastante sencilla? – user3600150