Categorías
hoy aprendí ...

… a decirle a git que deje de darle bola al cambio de modo de los archivos

git config core.fileMode false

Encontrado en https://stackoverflow.com/a/1580644

Con una explicación muy buena:

Try:

git config core.fileMode false

From git-config(1):

core.fileMode
    Tells Git if the executable bit of files in the working tree
    is to be honored.

    Some filesystems lose the executable bit when a file that is
    marked as executable is checked out, or checks out a
    non-executable file with executable bit on. git-clone(1)
    or git-init(1) probe the filesystem to see if it handles the 
    executable bit correctly and this variable is automatically
    set as necessary.

    A repository, however, may be on a filesystem that handles
    the filemode correctly, and this variable is set to true when
    created, but later may be made accessible from another
    environment that loses the filemode (e.g. exporting ext4
    via CIFS mount, visiting a Cygwin created repository with Git
    for Windows or Eclipse). In such a case it may be necessary
    to set this variable to false. See git-update-index(1).

    The default is true (when core.filemode is not specified
    in the config file).

The -c flag can be used to set this option for one-off commands:

git -c core.fileMode=false diff

Typing the -c core.fileMode=false can be bothersome and so you can set this flag for all git repos or just for one git repo:

# this will set your the flag for your user for all git repos (modifies `$HOME/.gitconfig`)
git config --global core.fileMode false

# this will set the flag for one git repo (modifies `$current_git_repo/.git/config`)
git config core.fileMode false

Additionally, git clone and git init explicitly set core.fileMode to true in the repo config as discussed in Git global core.fileMode false overridden locally on clone

Warning

core.fileMode is not the best practice and should be used carefully. This setting only covers the executable bit of mode and never the read/write bits. In many cases you think you need this setting because you did something like chmod -R 777, making all your files executable. But in most projects most files don’t need and should not be executable for security reasons.

The proper way to solve this kind of situation is to handle folder and file permission separately, with something like:

find . -type d -exec chmod a+rwx {} \; # Make folders traversable and read/write
find . -type f -exec chmod a+rw {} \;  # Make files read/write

If you do that, you’ll never need to use core.fileMode, except in very rare environment.

Categorías
hoy aprendí ...

… a reparar unos errores en GIT al hacer push

Quise realizar un push a un repositorio remoto y me soltó un error que nunca había visto:

remote: error: refs/tags/v2.0 does not point to a valid object!

Pensé que se trataba de algún archivo en el disco remoto que se había corrompido, pero cuando hice la prueba con otro repositorio obtuve un error similar (lo trato más abajo).

Lo que pude averiguar es que la referencia del tag v2.0 no apuntaba bien. La solución no está confirmada pero hice:

  • prune en el repo remoto
  • gc tambien en el remoto, aunque me soltaba un error también relacionado con el tag v2.0
  • desde el repo local borré el tag remoto
  • hice un prune y gc (me dio error)
  • luego el push del tag local al repo remoto y funcionó.

En el caso del otro repositorio el problema eran ramas y no etiquera, y varias.

Aquí lo que me funcionó fue: en el repo remoto editar el archivo packed-refs y eliminar las referencias de las ramas indicada, correr un prune y luego en un gc. En el repo local facer un prune y un fetch. Y funcionó.

No estoy totalmente seguro pero hay pasos que me parece que no hace falta.

Chau.

Categorías
hoy aprendí ...

… a implementar los metadatos en GIT

Hace tiempo que quiero guardar la fecha de los archivos cuando se hacen los commits en GIT y que al hacer el checkout vuelva a restaurarlos.

Había encontrado un par de soluciones, entre ellas:

Pregunta en stackoverflow.com acerca de la misma inquietud, en donde se exponen algunas propuestas, hacer un script ad Hoc, Metastore (que ya está como caido) y git-cache-meta que parece funcionar
git-cache-meta

Que tiene varias contribuciones, entre ellas una de danny0838 con una adaptación para msysgit

Y para utilizarlo de manera automática encontré en la misma pregunta una forma de utilizarlo, el mismo danny0838 hizo una versión más ligera pero que utilizar Perl y depende de commandos *nix.

https://github.com/danny0838/git-store-meta

Lo que logré fue adaptar los hooks en pre-commit y post-checkout para que lanze el comando.

Falta mejorarlo para que cuando se clona el proyecto por primera vez, instale los hooks de manera automática y hace el –apply de los metadatos.

copiar_hooks_client_side.sh

#!/bin/sh

# Copia los hooks de un repositorio de hooks a la carpeta del proyecto GIT desde donde se llama.

echo "Copiando HOOKS de GIT-CACHE-META-MSYSGIT al proyecto $PWD"
cp /ruta-al-repo-de-hooks/git-cache-meta-msysgit.sh $PWD/.git/hooks/git-cache-meta-msysgit.sh
cp /ruta-al-repo-de-hooks/post-checkout $PWD/.git/hooks/post-checkout
cp /ruta-al-repo-de-hooks/pre-commit $PWD/.git/hooks/pre-commit

pre-commit

#!/bin/sh
# when running the hook, cwd is the top level of working tree

# store
echo "Almacenar metadatos de archivos en el repo ..."
sh $(dirname "$0")/git-cache-meta-msysgit.sh --store || exit 1

# remember to add the updated cache file
git add .git_cache_meta

post-checkout

#!/bin/sh
# when running the hook, cwd is the top level of working tree

sha_old=$1
sha_new=$2
change_br=$3

# apply metadata only when the HEAD is changed
if [ ${sha_new} != ${sha_old} ]; then
 echo "Recuperar metadatos de archivos ..."
 sh $(dirname "$0")/git-cache-meta-msysgit.sh --apply
fi

Nota: para saber sobre los directorios en script bash (

$PWD

http://unix.stackexchange.com/questions/188182/how-to-get-current-working-directory