tag - Lista de todos los comandos que causan git gc--auto
git checkout tag (2)
¿Hay una lista definitiva de comandos en cualquier lugar que haga que git gc --auto
ejecute? La página del manual de git-gc (1) simplemente dice:
--auto
Con esta opción, git gc verifica si se requiere algún tipo de limpieza; Si no, sale sin realizar ningún trabajo. Algunos comandos de git ejecutan
git gc --auto
después de realizar operaciones que podrían crear muchos objetos sueltos.
(énfasis añadido)
Estoy en el proceso de organizar una gran migración de SVN a Git. La gran mayoría de los usuarios estarán en PC con Windows, y una parte no insignificante de ellos no es técnica. Utilizarán TortoiseGit (ya que se asemeja mucho a TortoiseSVN, con el que ya están familiarizados). Me he dado cuenta de que TortoiseGit no incluye ninguna funcionalidad para ejecutar git gc
manualmente.
No se puede esperar que el personal no técnico tenga que lanzar una línea de comandos "git bash" para ejecutar git gc --auto
desde el directorio de trabajo apropiado; y como estamos usando la distribución "portátil" de MsysGit, no tendrán el acceso directo del menú contextual del shell de Windows "Git GUI Here ..".
¿Es razonable esperar que, con el tiempo, Git se mantenga por sí solo o necesito intentar un método no técnico para invocar git gc --auto
?
Con Git 2.17 (Q2 2018), tendrá que agregar git commit
a la lista de comandos que activan un git gc --auto
.
En realidad, ese debería haber sido el caso desde el comienzo de Git.
Ver commit 095c741 (28 de febrero de 2018) por Ævar Arnfjörð Bjarmason ( avar
) .
(Fusionada por Junio C Hamano - gitster
- in commit 9bb8eb0 , 08 Mar 2018)
commit
: ejecutagit gc --auto
justo antes delgit gc --auto
post-commit
Cambie el comportamiento de
git-commit
nuevo a lo que era en d4bb43e ("Invoke"git gc --auto
"fromcommit
,merge
,am
yrebase
.", 2007-09-05, Git v1.5.4-rc0) cuando fuegit-commit.sh
.Poco después, en f5bbc32 ("Port
git commit
to C.", 2007-11-08, Git v1.5.4-rc0) cuando fue portado a C, la invocación "git gc --auto
" desapareció.Desde esa regresión no deseada,
git gc --auto
solo se ejecutó paragit-am
,git-merge
,git-fetch
ygit-receive-pack
.
Era posible escribir un script que "git commit
" una gran cantidad de datos localmente, ygc
nunca se ejecutaría.Un repositorio de este tipo que estaba comprometiendo localmente los cambios generados en el archivo de zona había crecido a un tamaño de ~ 60 GB antes de que se agregara un cronjob diario a "
git gc
", reduciéndolo a menos de 1 GB. Esto hará que tales casos funcionen sin intervención.Creo que arreglar esos casos patológicos en los que el repositorio crecerá para siempre es un intercambio valioso por gastar un par de milisegundos llamado "
git gc --auto
" (en los casos comunes en los que no hace nada).
builtin/merge.c: const char *argv_gc_auto[] = { "gc", "--auto", NULL };
builtin/receive-pack.c: "gc", "--auto", "--quiet", NULL,
git-am.sh: git gc --auto
git-rebase--interactive.sh: git gc --auto &&
git-svn.perl: command_noisy(''gc'', ''--auto'');
De git grep -- --auto
en git.git, los resultados parecían interesantes. El notable es builtin/merge.c
lo que significa que el git pull
siempre tan común debería disparar un git gc --auto
.
Además, a menos que su personal ''no técnico'' esté haciendo cosas más ''avanzadas'' (en cuyo punto ya no serían ''no técnicos''), no veo por qué necesitarían ejecutar git gc
manualmente. de solo dejar que git gc --auto
maneje todo.