Detta stämmer faktiskt inte, Git som verktyg har rätt rejäla begränsningar för vissa typer av filer. Ett repo kan bli stort av att ha väldigt lång historik och väldigt mycket källkod, vilket är fallet för Linux-kärnan. Men det är Git fortfarande bra på att hantera på grund av att det byggdes för just detta ändamål. Ordagrant, Torvalds (m.fl.) byggde Git för att versionshantera Linux. Men stora filer är något helt annat.
Man brukar säga att stora filer är lite utav en akilleshäl för Git, men i själva verket är akilleshälen binära filer, dvs filer som inte är menade att läsas som klartext. Stora filer tenderar dock att vara just binära, vilket antagligen är varför begreppen används för samma koncept. Med antagandet att TS 100MB stora fil är binär (vilket känns rätt sannolikt) så skulle jag säga att det var helt rimligt för denne att ta bort den ur historiken, särskilt med tanke på att det är ett privat projekt utan andra medverkande. Och jag ska såklart förklara varför.
På grund av att Git lagrar hela innehållet i en fil som en blob och därmed måste skapa en ny blob för minsta lilla ändring så växer repot snabbt om man har en binär fil som man gör ändringar i. En binär fil på 100 MB som du ändrar minsta lilla sak i och sedan committar, ja då har du ett repo som är 200 MB stort.
Läser man kapitlet i Git-boken som nämner lagring av stora källkodsfiler så kan man tro att detta inte är något större problem eftersom Git packar ihop liknande objekt i packfiles och lagrar deltan mellan dessa. Det som tyvärr inte framgår här är att Git från topp till tå är optimerat för att lagra klartext. Så att lagra flera versioner av en 100 MB binär fil är ett ganska stort problem, medan samma sak fö` en 100 MB stor CSV-fil med något dataset inte kommer att få repot att växa på samma sätt på grund av att den är klartext och deltan därmed kan beräknas från en version till en annan.
Vi kan göra ett litet experiment med en snarlik version av exemplet jag hade ovan, där vi committar PDFen som det står "Hej!" i (som till största del är binärt nonsens). PDFen i sig är ca 24KB, och även i komprimerad blob-form är den ca 24KB (den är faktiskt några hundra byte mindre i blobformen i detta fall).
$ ls -l -h
total 28K
-rw-r--r-- 1 simplar simplar 5 Jul 16 10:33 README.md
-rw-r--r-- 1 simplar simplar 24K Jul 16 10:33 README.pdf
$ git hash-object README.pdf # <-- to determine object hash to find it in the database
73d3e81c91e7581f984ba50e311cec4b8744689a
$ ls -l -h .git/objects/73/d3e81c91e7581f984ba50e311cec4b8744689a
-r--r--r-- 1 simplar simplar 24K Jul 16 10:35 .git/objects/73/d3e81c91e7581f984ba50e311cec4b8744689a
Om vi packar denna i en packfile (Git gör detta automatiskt vid vissa tillfällen) så får vi i praktiken samma storlek som blobben, eftersom en "bas" måste sparas i sin helhet.
$ git repack
$ ls -l -h .git/objects/pack/
total 32K
-r--r--r-- 1 simplar simplar 1.2K Jul 16 10:49 pack-79c806373a2e0fd3f96a4fea204b8bf04bb6d2c3.idx
-r--r--r-- 1 simplar simplar 24K Jul 16 10:49 pack-79c806373a2e0fd3f96a4fea204b8bf04bb6d2c3.pack
-r--r--r-- 1 simplar simplar 68 Jul 16 10:49 pack-79c806373a2e0fd3f96a4fea204b8bf04bb6d2c3.rev
Om vi nu ändrar något litet, exempelvis ändrar texten från "Hej!" till "Hej" och kompilerar om PDFen kommer den ha nära identisk storlek och innehåll i praktiken. Comittar vi den får vi som sagt en ny blob som också är 24KB, men det intressanta är att packfilen blir dubbelt så stor, vilket i praktiken gör att repot för all framtid kommer vara dubbelt så stort (om vi inte får en ny algoritm för att packa packfiler).
$ ls -l -h
total 28K
-rw-r--r-- 1 simplar simplar 4 Jul 16 10:58 README.md
-rw-r--r-- 1 simplar simplar 24K Jul 16 10:33 README.pdf
$ ls -l -h .git/objects/pack/
total 56K
-r--r--r-- 1 simplar simplar 1.4K Jul 16 11:00 pack-6c7d064fa855062137a6c6af6039dcbfe88c77da.idx
-r--r--r-- 1 simplar simplar 48K Jul 16 11:00 pack-6c7d064fa855062137a6c6af6039dcbfe88c77da.pack
-r--r--r-- 1 simplar simplar 92 Jul 16 11:00 pack-6c7d064fa855062137a6c6af6039dcbfe88c77da.rev
Om jag istället tar en godtycklig källkodsfil från Linux-kärnan på ca 38KB och gör samma sak får jag ett helt annat resultat på grund av att den är klartext.
$ git add arraymap.c
$ git commit -m 'Add arraymap.c'
$ git repack
$ ls -l -h .git/objects/pack/
[...]
-r--r--r-- 1 simplar simplar 8.8K Jul 16 11:15 pack-a355016827401876bb13400a4a5e084c8d8e6db5.pack
$ echo '// hello there' >> arraymap.c
$ git commit -am 'Append greeting'
$ git repack
$ ls -l -h .git/objects/pack/
[...]
-r--r--r-- 1 simplar simplar 9.0K Jul 16 11:17 pack-ca725db684ea1735cae3ddf3055b44c09c19d55e.pack
[...]
Inte nog med att den initiala packfilen blev betydligt mindre än källfilen på grund av att komprimeringen (som är zlib) faktiskt hade någon effekt, utan den andra packfilen som innehåller två versioner av filen blev bara ett par hundra byte större! Det är precis detta Git är byggt för, versioner av klartextfiler med små skillnader mellan varje version.
Det finns alltså väldigt goda tekniska anledningar till att inte versionshantera stora binära filer med Git. Det är helt enkelt inte byggt för det. Där har vi istället tillägg såsom Git LFS som får göra grovjobbet med att spara datan, medan Git håller koll på var vardera version hör hemma i historiken.
Inget av det du säger motsäger något som jag skrev. Precis som du skriver är inte Git optimalt för att versionshantera stora binära filer, men om det t.ex. är några enstaka bilder som är 1 MB stora som ändras ganska sällan (t.ex. assets för ett spel) så hade många idag resonerat att bekvämligheten att ha dem i samma repo överväger att Git inte är optimalt utformat för att hantera binär data. Däremot kanske inte för 20 år sedan då hårddiskar var betydligt mindre. Och i framtiden så kommer också större binära filer accepteras i Git, eftersom de inte är stora nog för att ställa till ett problem.
Det är en tradeoff, diskutrymme mot smidighet. Och den tradeoffen kommer alltid se olika ut för olika personer och projekt, och den lagringsteknik som är tillgänglig vid tillfället.
