Jakie są limity plików w Git (liczba i rozmiar)?

Czy ktoś wie, jakie są limity Gita dotyczące liczby plików i rozmiaru plików?

Ta wiadomość od samego Linusa może ci pomóc z innymi ograniczeniami

[...] CVS, tj. Tak naprawdę kończy się na tym, że jest prawie zorientowany na model „jeden plik na raz”.

Co jest fajne, ponieważ możesz mieć milion plików, a potem sprawdzić tylko kilka z nich - nigdy nie zobaczysz wpływu pozostałych 999,995 plików.

Git zasadniczo nigdy nie wygląda na mniej niż całe repozytorium. Nawet jeśli trochę ograniczysz rzeczy (np. Sprawdzisz tylko część lub historię cofniesz trochę), git nadal zawsze troszczy się o całość i przenosi wiedzę.

Więc git skaluje się naprawdę źle, jeśli zmusisz go do patrzenia na wszystko jak na jedno ogromne repozytorium. Nie wydaje mi się, aby ta część była naprawdę możliwa do naprawienia, chociaż prawdopodobnie możemy to poprawić.

I tak, są też problemy z „dużymi plikami”. Naprawdę nie wiem, co zrobić z dużymi plikami. Wiem, że ich jesteśmy do niczego.

Zobacz więcej w mojej innej odpowiedzi : ograniczenie w Git polega na tym, że każde repozytorium musi reprezentować „ spójny zestaw plików ”, „cały system” sam w sobie (nie można oznaczyć „części repozytorium”).
Jeśli Twój system składa się z autonomicznych (ale współzależnych) części, musisz użyć modułów podrzędnych .

Jak ilustruje odpowiedź Talljoe , limitem może być systemowy (duża liczba plików), ale jeśli rozumiesz naturę Gita (o spójności danych reprezentowanej przez jego klucze SHA-1), zdasz sobie sprawę z prawdziwego „ograniczenia” jest użytkowa : tj. nie powinieneś próbować przechowywać wszystkiego w repozytorium Git, chyba że jesteś przygotowany, aby zawsze odzyskać lub oznaczyć wszystko z powrotem. W przypadku niektórych dużych projektów nie miałoby to sensu.

Aby uzyskać bardziej szczegółowe informacje na temat limitów git, zobacz „ git with large files ”
(który wspomina o git-lfs : rozwiązanie do przechowywania dużych plików poza repozytorium git. GitHub, kwiecień 2015)

Trzy kwestie, które ograniczają repozytorium git:

• ogromne pliki ( xdelta dla packfile jest tylko w pamięci, co nie jest dobre w przypadku dużych plików)
• ogromna liczba plików , co oznacza jeden plik na obiekt blob i powolne generowanie jednego pliku pakietu na raz przez git gc.
• ogromne pliki paczek , z indeksem pliku pakietu nieefektywnym do pobierania danych z (ogromnego) pliku pakietu.

Nowszy wątek (luty 2015) ilustruje czynniki ograniczające repozytorium Git :

Czy kilka jednoczesnych klonów z serwera centralnego również spowolni inne równoczesne operacje dla innych użytkowników?

Podczas klonowania serwer nie jest blokowany, więc w teorii klonowanie nie wpływa na inne operacje. Klonowanie może jednak zużywać dużo pamięci (i dużo procesora, chyba że włączysz funkcję bitmapy osiągalności, co powinieneś).

Czy git pullbędzie powolny?

Jeśli wykluczymy stronę serwera, rozmiar twojego drzewa jest głównym czynnikiem , ale twoje pliki 25k powinny wystarczyć (Linux ma 48k plików).

' git push'?

Na to nie ma wpływu, jak głęboka jest historia repozytorium ani jak szerokie jest Twoje drzewo, więc powinno być szybkie.

Ach, liczba referencji może wpływać zarówno na, jak git-pushi git-pull.
Myślę, że Stefan wie lepiej niż ja w tej dziedzinie.

' git commit'? (Jest wymieniony jako wolny w referencji 3. ) ' git status'? (Znowu zwolnij w odniesieniu 3, chociaż go nie widzę.)
(Również git-add)

Ponownie, rozmiar twojego drzewa. Przy wielkości twojego repozytorium nie sądzę, żebyś musiał się tym martwić.

Niektóre operacje mogą wydawać się nie codzienne, ale jeśli są często wywoływane przez interfejs WWW do GitLab / Stash / GitHub itp., Mogą stać się wąskimi gardłami. (np. „ git branch --contains” wydaje się bardzo niekorzystnie wpływać na dużą liczbę oddziałów).

git-blame może działać wolno, gdy plik jest często modyfikowany.

Nie ma prawdziwego limitu - wszystko nosi nazwę 160-bitową. Rozmiar pliku musi być reprezentowalny w postaci liczby 64-bitowej, więc nie ma też rzeczywistego ograniczenia.

Jest jednak praktyczny limit. Mam repozytorium o wielkości ~ 8 GB z> 880 000 plików i git gc zajmuje trochę czasu. Drzewo robocze jest dość duże, więc operacje sprawdzające cały katalog roboczy zajmują sporo czasu. To repozytorium służy jednak tylko do przechowywania danych, więc to tylko kilka zautomatyzowanych narzędzi, które je obsługują. Wyciąganie zmian z repozytorium jest dużo, dużo szybsze niż rsynowanie tych samych danych.

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

Jeśli dodasz pliki, które są zbyt duże (GB w moim przypadku, Cygwin, XP, 3 GB RAM), spodziewaj się tego.

fatal: brak pamięci, malloc nie powiódł się

Więcej szczegółów tutaj

Aktualizacja 3/2/11: Widziałem podobne w Windows 7 x64 z Tortoise Git. Mnóstwo używanej pamięci, bardzo wolna odpowiedź systemu.

W lutym 2012 r. Na liście mailingowej Git pojawił się bardzo interesujący wątek Joshua Redstone, inżyniera oprogramowania Facebooka testującego Git w ogromnym repozytorium testowym:

Repozytorium testów ma 4 miliony zatwierdzeń, liniową historię i około 1,3 miliona plików.

Przeprowadzone testy pokazują, że dla takiego repozytorium Git jest bezużyteczny (zimna operacja trwa kilka minut), ale może się to zmienić w przyszłości. Zasadniczo wydajność jest obniżana przez liczbę stat()wywołań modułu FS jądra, więc będzie ona zależeć od liczby plików w repozytorium i wydajności buforowania FS. Zobacz także to streszczenie do dalszej dyskusji.

Na dzień 2018-04-20 Git dla Windows ma błąd, który skutecznie ogranicza rozmiar pliku do maksymalnie 4 GB przy użyciu tej konkretnej implementacji (ten błąd rozprzestrzenia się również na LFS ).

To zależy od twojego znaczenia. Istnieją praktyczne ograniczenia rozmiaru (jeśli masz dużo dużych plików, może to być nudno wolne). Jeśli masz dużo plików, skanowanie również może przebiegać wolno.

Model nie ma jednak nieodłącznych ograniczeń. Z pewnością możesz go słabo używać i być nieszczęśliwym.

Myślę, że dobrze jest unikać zatwierdzeń dużych plików, ponieważ są one częścią repozytorium (np. Zrzut bazy danych może być lepszy w innym miejscu), ale jeśli weźmie się pod uwagę rozmiar jądra w jego repozytorium, prawdopodobnie można spodziewać się wygodnej pracy z czymkolwiek mniejszym i mniej złożonym.

Mam dużą ilość danych przechowywanych w moim repozytorium jako pojedyncze fragmenty JSON. W kilku katalogach znajduje się około 75 000 plików i nie ma to negatywnego wpływu na wydajność.

Sprawdzanie ich za pierwszym razem było oczywiście trochę powolne.

Znalazłem to, próbując przechowywać ogromną liczbę plików (350k +) w repozytorium. Tak, sklep. Śmiech.

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total

Poniższe fragmenty dokumentacji Bitbucket są dość interesujące.

Kiedy pracujesz z klonowaniem i wypychaniem repozytorium DVCS, pracujesz z całym repozytorium i całą jego historią. W praktyce, gdy repozytorium będzie większe niż 500 MB, możesz zacząć widzieć problemy.

... 94% klientów Bitbucket ma repozytoria o rozmiarze poniżej 500 MB. Zarówno jądro systemu Linux, jak i Android mają mniej niż 900 MB.

Zalecanym rozwiązaniem na tej stronie jest podzielenie projektu na mniejsze części.

git ma limit 4G (32-bitowy) dla repozytorium.

http://code.google.com/p/support/wiki/GitFAQ