Git extrae nombres de archivos de Windows no válidos

Estoy trabajando en un proyecto compartido usando git para el control de versiones. Estoy en Windows mientras mi pareja está en Unix.

Mi compañero ha nombrado algunos archivos con <file1>.txt. Cuando trato de extraer estos archivos, no se aceptan como < y > son caracteres no válidos para Windows. Esto está bien, no necesito tocar los archivos. Sin embargo, se agregan a mi compromiso como eliminados. Entonces, si presiono, eliminaré estos archivos que no quiero hacer.

1. no puedo usar git reset --hard ya que encuentra una ruta no válida para cada uno de estos archivos “eliminados”.

2. ¿Hay alguna forma de excluir estos archivos de mis confirmaciones? He intentado agregar <file1> para mi .git/info/exclude pero eso no funcionó.

Necesitará que su socio cambie los nombres para que sea algo que también sea válido en Windows. Después de que les hayan cambiado el nombre, lo que haría es esto:

1. Realice una copia de seguridad de los cambios que solo tenga localmente (tanto los no confirmados como los confirmados pero no enviados).
2. Correr git reset --hard <commit> donde <commit> es cualquier compromiso anterior a que se agregaran los archivos.
3. Correr git pull para llegar hasta la última revisión (donde se cambia el nombre de los archivos).
4. Restaure sus cambios respaldados desde 1.

Esto debería obtener la revisión más reciente donde los archivos no se nombran en esto, en Windows, de manera ilegal, y el sistema operativo no los eliminará (ni los creará nunca) desde debajo de git 🙂

PD: Sé que esta es una vieja pregunta, pero he tenido este problema recientemente, así que espero que la solución a la que he llegado pueda ayudar a otros también.

EDITAR:

Para evitar que esto vuelva a suceder, su socio puede agregar un gancho de confirmación previa que evitará que confirme archivos con nombres que no estarían permitidos en Windows. Hay una muestra/ejemplo a menudo en pre-commit.sample. Cambié un poco el bit en el pasado y terminé con algo como:

# Cross platform projects tend to avoid non-ASCII filenames; prevent
# them from being added to the repository. We exploit the fact that the
# printable range starts at the space character and ends with tilde.
if [ "$allownonascii" != "true" ] &&
    # Note that the use of brackets around a tr range is ok here, (it's
    # even required, for portability to Solaris 10's /usr/bin/tr), since
    # the square bracket bytes happen to fall in the designated range.
    echo $(git diff --cached --name-only --diff-filter=A -z $against | LC_ALL=C)
    test $(git diff --cached --name-only --diff-filter=A -z $against |
      LC_ALL=C tr -d '[ !#-)+-.0-9;=@-[]-{}~]\0' | wc -c) != 0
then
    cat <<\EOF
Error: Attempt to add a non-ASCII file name.

This can cause problems if you want to work with people on other platforms.

To be portable it is advisable to rename the file.

If you know what you are doing you can disable this check using:

  git config hooks.allownonascii true
EOF
    exit 1
fi

los '[ !#-)+-.0-9;=@-[]-{}~]\0' bit es la parte importante que he cambiado un poco. Define todos los rangos de caracteres permitidos, y el ejemplo solo no permite caracteres “no ascii” (que es lo que dice el comentario en la parte superior), pero también hay caracteres ascii que no están permitidos en los nombres de archivos en Windows (como como ? y :).

Se eliminan todos los caracteres permitidos, y si queda algo (wc -c != 0) falla. Puede ser un poco difícil de leer, ya que no puede ver ninguno de los caracteres no permitidos. Es útil si tiene una lista de los rangos de caracteres para mirar al leerla o editarla.

Ignorar no ayuda si los archivos ya están rastreados.

Utilizar Pago escaso para omitir esos archivos.