Monitorizar cambios en directorios con Git y construir Lume

Hola, soy Munou.
Hace un tiempo,
reconstruir solo cuando hay un cambio en LumeCMS, un SSG de sitio estático, usando inotifywait
Lo configuré para que se construyera automáticamente con esto, pero también se activaba cuando se creaban archivos de intercambio de vim, los procesos morían sin que me diera cuenta y las construcciones se ejecutaban innecesariamente, lo que lo hacía bastante inestable. Así que pensé: "Si lo gestiono con git, puedo ejecutar el flujo de construcción cuando haya cambios y puedo revertir si algo sale mal, lo cual sería bueno". Como ya tenía algunas ideas de scripts de shell en mente, decidí intentarlo.

Así es como se ve

Aquí está el código desde el principio, de forma concisa.
También está disponible en Github.

#!/bin/bash

LUME_DIR="/your/lume/dir"
SRC_DIR="$LUME_DIR/src"
BUILD_DIR="site"
WEBPSH="/your/webp/convert/path"
COMMIT_COMMENT="`echo "Memory" && free -h | head -2 | awk  '{print $(NF-5)"," $(NF-4)"," $(NF-3)}' | column -t -s ","`"

export DENO_INSTALL="/home/$USER/.deno"
export PATH="$DENO_INSTALL/bin:$PATH"

cd "$SRC_DIR" || exit
ls "$SRC_DIR/.git" || git init || exit
git add . || exit

git commit -m "$COMMIT_COMMENT"

if [ $? -eq 0 ]; then
  $WEBPSH
  cd $LUME_DIR || exit
  # deno task lume --dest=$BUILD_DIR
  deno task lume --dest=$BUILD_DIR > /dev/null 2>&1
else
  exit 1
fi

De todos modos, quería implementarlo con el código más corto posible, así que esto es lo que obtuve.
Bueno, el COMMIT_COMMENT es un poco desordenado, pero es solo por diversión...

Al principio, registraba la hora con date, pero luego me di cuenta de que ya se puede verificar con git log, así que no es necesario, ¿verdad?
(Quizás incluso podría poner algún arte ASCII aleatorio...)

El script que se muestra en la imagen se ejecuta cada 5 minutos a través de cron.

Veamos los valores de retorno de Git

De todos modos, parece que el valor de retorno al ejecutar git add . en Git no detecta cambios. Por ejemplo, el valor de retorno cuando git init no se ha ejecutado:

alleycat:[haturatu]:~/git/gittest$ ls -la
合計 8
drwxr-xr-x  2 haturatu haturatu 4096 10月 14 01:08 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
alleycat:[haturatu]:~/git/gittest$ git add .
fatal: not a git repository (or any of the parent directories): .git
alleycat:[haturatu]:~/git/gittest$ echo $?
128

Es 128.
Ahora, creemos o eliminemos archivos después de ejecutar git init.

alleycat:[haturatu]:~/git/gittest$ ls -la
合計 12
drwxr-xr-x  3 haturatu haturatu 4096 10月 14 01:11 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
drwxr-xr-x  7 haturatu haturatu 4096 10月 14 01:11 .git
alleycat:[haturatu]:~/git/gittest$ git add .
alleycat:[haturatu]:~/git/gittest$ echo $?
0
alleycat:[haturatu]:~/git/gittest$ touch test
alleycat:[haturatu]:~/git/gittest$ ls -la
合計 12
drwxr-xr-x  3 haturatu haturatu 4096 10月 14 01:11 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
drwxr-xr-x  7 haturatu haturatu 4096 10月 14 01:11 .git
-rw-r--r--  1 haturatu haturatu    0 10月 14 01:11 test
alleycat:[haturatu]:~/git/gittest$ git add .
alleycat:[haturatu]:~/git/gittest$ echo $?
0

Por lo tanto, git add . no cambia el valor de retorno, lo que significa que no puede detectar cambios.
Entonces, veamos el valor de retorno cuando se ejecuta commit.

alleycat:[haturatu]:~/git/gittest$ git commit -m "nyaa"
[master (root-commit) 60bed93] nyaa
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test
alleycat:[haturatu]:~/git/gittest$ echo $?
0
alleycat:[haturatu]:~/git/gittest$ git commit -m "nyan nyan"
On branch master
nothing to commit, working tree clean
alleycat:[haturatu]:~/git/gittest$ echo $?
1

Parece que si no hay cambios, se devuelve 1.
Así que, podemos determinarlo a partir de este valor de retorno, y el resto es fácil.

La monitorización de cambios parece bastante profunda

Así que, este método parece un enfoque de gestión de cambios que podría ser útil en otros lugares.
Sin embargo, lo que he estado explorando constantemente es cómo monitorear los cambios en los directorios de forma más fácil, ligera y recursiva, lo cual parece simple pero no lo es.
En el caso del comando find, es un comando muy potente, por lo que ejecutarlo para la monitorización de cambios puede ser bastante engorroso (¿me pregunto si Git también lo ejecuta como un comando interno?).
Si tienes que escribir tu propio código de monitorización de cambios, también necesitas incluir comprobaciones para los directorios excluidos. En este sentido, la monitorización de cambios de Git es superior porque puedes excluir eficazmente los directorios innecesarios de la monitorización simplemente listándolos en .gitignore.

En este aspecto, Git es muy superior.
Sin embargo, en el caso de Git, almacena cachés en .git, por lo que podría no ser adecuado para monitorear directorios con archivos grandes. Por lo tanto, se podría hacer un hash de cada archivo, almacenarlo como un archivo de texto en /tmp, tomar un un diff, y si se devuelve un valor de retorno que indica una diferencia, entonces proceder con el flujo de cambios.
Algo así podría ser posible.
Sin embargo, si tuviera que añadir código para excluir archivos, ordenar antes de hacer el diff, etc., probablemente se volvería bastante complejo, así que preferiría no hacerlo.

Mientras escribía, pensé...

Ni siquiera necesito ejecutar find; simplemente puedo enviar la salida de ls -laR a /tmp y tomar el diff.
Pero, ¿por qué Git se siente más ligero...? Si sigo por ese camino, siento que tendré que empezar a desentrañar Git, así que lo dejaré aquí por hoy.

Bueno, hasta la próxima, gracias.