que - Limitar el tamaño del archivo en el repositorio de git

git push tag

Question

Actualmente estoy pensando en cambiar mi VCS (de subversión) a git. ¿Es posible limitar el tamaño del archivo dentro de un commit en un repositorio de git? Por ejemplo, subversión, hay un enlace: http://www.davidgrant.ca/limit_size_of_subversion_commits_with_this_hook

Según mi experiencia, las personas, especialmente las que no tienen experiencia, a veces tienden a enviar archivos que no deberían entrar en un VCS (por ejemplo, imágenes de un gran sistema de archivos).

Answer 1

Este será un caso muy raro de lo que he visto cuando alguien ingresa, digamos un archivo de 200 Mb o incluso más.

Si bien puede evitar que esto suceda mediante el uso de ganchos del lado del servidor (no está seguro de los ganchos del lado del cliente, ya que tiene que confiar en la persona que tiene los ganchos instalados), como en SVN, también debe tener en cuenta que en Git , es mucho más fácil eliminar dicho archivo / confirmación del repositorio. No tenías tanto lujo en SVN, al menos no es una manera fácil.

Answer 2

Otra forma es versionar .gitignore , lo que evitará que cualquier archivo con una cierta extensión se muestre en el estado.
También puede tener ganchos (en sentido descendente o ascendente, según lo sugerido por las otras respuestas), pero al menos todo el repo .gitignore puede incluir ese .gitignore para evitar agregar .exe , .dll , .iso , ...

Answer 3

Puede usar un gancho , ya sea pre-commit hook (en el cliente), o un gancho de update (en el servidor). Haga un git ls-files --cached (para pre-commit) o git ls-tree --full-tree -r -l $3 (para actualización) y actúe en consecuencia.

git ls-tree -l daría algo como esto:

100644 blob 97293e358a9870ac4ddf1daf44b10e10e8273d57 3301 file1
100644 blob 02937b0e158ff8d3895c6e93ebf0cbc37d81cac1 507 file2

Toma la cuarta columna, y es el tamaño. Utilice git ls-tree --full-tree -r -l HEAD | sort -k 4 -n -r | head -1 git ls-tree --full-tree -r -l HEAD | sort -k 4 -n -r | head -1 git ls-tree --full-tree -r -l HEAD | sort -k 4 -n -r | head -1 para obtener el archivo más grande. cut para extraer, if [ a -lt b ] para verificar el tamaño, etc.

Lo siento, creo que si eres un programador, deberías poder hacerlo tú mismo.

Answer 4

Estoy usando gitolita y el gancho de actualización ya estaba en uso: en lugar de usar el gancho de actualización, utilicé el gancho de pre-recepción. El guión publicado por Chriki funcionó fabulosamente con la excepción de que los datos se pasan a través de stdin, así que hice un cambio de línea:

- refname=$3
+ read a b refname

(Puede haber una manera más elegante de hacerlo, pero funciona)

Answer 5

Si está usando gitolita también puede probar VREF. Hay un VREF ya proporcionado por defecto (el código está en gitolite / src / VREF / MAX_NEWBIN_SIZE). Se llama MAX_NEWBIN_SIZE. Funciona así:

repo name
RW+ = username
- VREF/MAX_NEWBIN_SIZE/1000 = usernames

Donde 1000 es un umbral de ejemplo en Bytes.

Este VREF funciona como un gancho de actualización y rechazará su inserción si un archivo que va a presionar es mayor que el umbral.

Answer 6

Las respuestas de eis y J-16 SDiZ adolecen de un grave problema. Solo están verificando el estado de la apuesta final $ 3 o $ newrev. También deben verificar lo que se envía en las otras confirmaciones entre $ 2 (o $ oldrev) y $ 3 (o $ newrev) en el gancho de udpate.

J-16 SDiZ está más cerca de la respuesta correcta.

El gran defecto es que alguien cuyo servidor departamental tiene instalado este gancho de actualización para protegerlo descubrirá de la peor manera que:

Después de usar git rm para eliminar el archivo grande que se ha registrado accidentalmente, el árbol actual o la última confirmación solo estarán bien, y atraerá toda la cadena de confirmaciones, incluido el archivo grande que se eliminó, creando una grasa hinchada e infeliz. historia que nadie quiere

La solución es verificar cada confirmación de $ oldrev a $ newrev, o especificar todo el rango $ oldrev .. $ newrev. Asegúrate de que no solo estás comprobando $ newrev solo, o si esto no funciona con basura masiva en tu historial de git, empujado a compartir con otros, y luego difícil o imposible de eliminar después de eso.

Answer 7

Sí, git también tiene ganchos ( git hooks ). Pero depende de la corriente de trabajo que usará.

Si tiene usuarios inexpertos, es mucho más seguro tirar, luego dejarlos presionar. De esta forma, puedes asegurarte de que no arruinen el repositorio principal.

Answer 8

Mientras luchaba con él por un tiempo, incluso con la descripción, y creo que esto también es relevante para otros, pensé en publicar una implementación de cómo se podría implementar lo que J16 SDiZ describió .

Por lo tanto, mi opinión sobre el gancho de update lado del servidor impide que se empujen archivos demasiado grandes:

#!/bin/bash
# Script to limit the size of a push to git repository.
# Git repo has issues with big pushes, and we shouldn''t have a real need for those
#
# eis/02.02.2012
# --- Safety check, should not be run from command line
if [ -z "$GIT_DIR" ]; then
echo "Don''t run this script from the command line." >&2
echo " (if you want, you could supply GIT_DIR then run" >&2
echo " $0 <ref> <oldrev> <newrev>)" >&2
exit 1
fi
# Test that tab replacement works, issue in some Solaris envs at least
testvariable=`echo -e "/t" | sed ''s//s//''`
if [ "$testvariable" != "" ]; then
echo "Environment check failed - please contact git hosting." >&2
exit 1
fi
# File size limit is meant to be configured through ''hooks.filesizelimit'' setting
filesizelimit=$(git config hooks.filesizelimit)
# If we haven''t configured a file size limit, use default value of about 100M
if [ -z "$filesizelimit" ]; then
filesizelimit=100000000
fi
# Reference to incoming checkin can be found at $3
refname=$3
# With this command, we can find information about the file coming in that has biggest size
# We also normalize the line for excess whitespace
biggest_checkin_normalized=$(git ls-tree --full-tree -r -l $refname | sort -k 4 -n -r | head -1 | sed ''s/^ *//;s/ *$//;s//s/{1,/}/ /g'' )
# Based on that, we can find what we are interested about
filesize=`echo $biggest_checkin_normalized | cut -d '' '' -f4,4`
# Actual comparison
# To cancel a push, we exit with status code 1
# It is also a good idea to print out some info about the cause of rejection
if [ $filesize -gt $filesizelimit ]; then
# To be more user-friendly, we also look up the name of the offending file
filename=`echo $biggest_checkin_normalized | cut -d '' '' -f5,5`
echo "Error: Too large push attempted." >&2
echo >&2
echo "File size limit is $filesizelimit, and you tried to push file named $filename of size $filesize." >&2
echo "Contact configuration team if you really need to do this." >&2
exit 1
fi
exit 0