Jak usunąć bardzo duże repozytorium .git?

Dzień dobry, posiadam VPS z ubuntem 20.04 LTS. Kiedyś na maszynce zainstalowałem git (apt install git), na VPS mam 320GB ostatnio zabrałem się za oczyszczanie serwera bo mam już zajęcie w 80%, i zauważyłem ze w folderze /etc mam folder .git(/etc/.git) który zajmuje prawie 100GB tak jak bym kiedyś przez przypadek stworzył rego które chyba tworzy backup całego systemu bo aż tyle zajmuje miejsca... Odinstalowałem git (apt remove git) następnie ponownie zainstalowałem gita lecz folder nadal tam jest, mogę go po prostu tak sobie usunąć?

Folder .git/ to po prostu folder z metadanymi repozytorium gitowego. Co oznacza, że z jakiegoś powodu /etc jest repozytorium. Przed usunięciem to bym najpierw sprawdził .git/config, żeby się dowiedzieć, skąd to się wzięło.

W configu mam

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true

Do odważnych świat należy !
Kasuj !

ewentualnie w folderze /etc polecenie git log może Cię natchnie skad to sie wzielo

No właśnie co to jest i skąd mogło się wziąć? Ja nigdy nie robiłem ręcznie repo... Jedynie co się domyślam to może podczas instalowania panelu do zarządzania serwera kilka ich testowałem ostatecznie pozostałem przy webmin virtualmin.

dsxsoft napisał(a):

No właśnie co to jest i skąd mogło się wziąć? Ja nigdy nie robiłem ręcznie repo... Jedynie co się domyślam to może podczas instalowania panelu do zarządzania serwera kilka ich testowałem ostatecznie pozostałem przy webmin virtualmin.

Coś albo ktoś musiało stworzyć w /etc repozytorium gitowe. Ja obstawiam że to był ktoś, który zrobił git clone albo git init.

Masz dwie opcje:

• Albo usuń w p*.
• Albo dowiedz się skąd to się wzięło:
  • Możesz np wykonać cd /etc oraz git remote, żeby sprawdzić czy są jakieś remote'y. Jak są (np znajdziesz origin), to zrób git remote get-url origin - może to Ci podpowie skąd się repo wzięło
  • Jak nie ma remoteów, to sprawdź git log, i zobacz kto albo co tam coś commitowało. Jak nie ma żadnych commit'ów, to możesz spokojnie usuwać.

@Riddle razem z @szatkus1: kurde zacny towar milordy. Repo w katalogu systemowym oraz sugerowanie usunięcia owego katalogu? Nie no, informatycy first-class......
@dsxsoft: stailuj sobie git log do ostatnich 10-20 rekordów, wrzuć wynik do pliku a plik do jakiegoś parsera (polecam sed) porównuj LBL........

Zapewne sobie zainstalowałeś etckeeper, sprawdź czy masz folder /etc/etckeeper
https://ubuntu.com/server/docs/tools-etckeeper
I po prostu usuń jak nie potrzebujesz albo przez

sudo etckeeper uninit

Być może miałeś go out of the box w obrazie z którego instalowałeś system na vps bo cytując wyżej wymienioną stronkę:

Placing /etc under version control is considered an industry best practice

W sumie pierwsze słyszę ale ma to sens żeby szybko naprawić swoje pomyłki. Jak chcesz to zachować ale zmniejszyć rozmiar to możesz usunąć i zainicjować od zera, stracisz historię zmian i możliwość powrotu do starej konfiguracji ale jeśli teraz wszystko działa to ok.

mustang_ex napisał(a):

@dsxsoft: stailuj sobie git log do ostatnich 10-20 rekordów, wrzuć wynik do pliku a plik do jakiegoś parsera (polecam sed) porównuj LBL........

Porównuj z czym?
Nie no koleś ma własny prywatny VPS, utworzył sobie repo przypadkiem pewnie którego nie używa a ty mu każesz to przeglądać nie wiadomo po co

Jeżeli o rozmiar chodzi to zawsze można jeszcze dać git gc
Wątpię jednak żeby udało się wiele zaoszczędzić.

Placing /etc under version control is considered an industry best practice

@obscurity no, zajebista praktyka.... taka nie za bardzo zgodna z przepisami (GDPR) ale w sumie kogo to interesuje, co?

mustang_ex napisał(a):

Placing /etc under version control is considered an industry best practice

@obscurity no, zajebista praktyka.... taka nie za bardzo zgodna z przepisami (GDPR) ale w sumie kogo to interesuje, co?

trzymasz dane klientów w etc czy co? Przecież to lokalne repo, co to zmienia

obscurity napisał(a):

mustang_ex napisał(a):

Placing /etc under version control is considered an industry best practice

@obscurity no, zajebista praktyka.... taka nie za bardzo zgodna z przepisami (GDPR) ale w sumie kogo to interesuje, co?

trzymasz dane klientów w etc czy co? Przecież to lokalne repo, co to zmienia

Nie tylko dane klientów są chronione GDPR em..... /etc zawiera pliki konfiguracyjne systemu jak i różnych jego składowych, które, z kolei, zawierają (bądź mogą zawierać) dane wrażliwe jak adresy IP sieci wewnętrznej, dane dostępowe do różnych aplikacji webowych intranetowych itp.

mustang_ex napisał(a):

Nie tylko dane klientów są chronione GDPR em..... /etc zawiera pliki konfiguracyjne systemu jak i różnych jego składowych, które, z kolei, zawierają (bądź mogą zawierać) dane wrażliwe jak adresy IP sieci wewnętrznej, dane dostępowe do różnych aplikacji webowych intranetowych itp.

Pomijając że IP sieci wewnętrznej to raczej nie są dane podlegające ochronie przez GDPR to jak zrobisz ich kopie w tym samym folderze obok to nagle łamane jest prawo?

jeśli repozytorium .git łamie gdpr/rodo, to w takim razie automatyczne backupy, przywracanie systemu i snapshoty dyskowe również, czyż nie? gitowy commit to nic innego jak snapshot repozytorium.

gitowy commit to nic innego jak snapshot repozytorium.

@Wibowit chyba w to nie wierzysz, co?

mustang_ex napisał(a):

gitowy commit to nic innego jak snapshot repozytorium.

@Wibowit chyba w to nie wierzysz, co?

precyzując: gitowy commit to snapshot repozytorium + metadane o commicie + hashe parentów (dwa dla merge'a lub jeden dla zwykłego commita). to, że zajętość dyskowa nie rośnie wprost proporcjonalnie z liczbą commitów i rozmiarem repozytorium podczas robienia tych commitów jest efektem tego, że git deduplikuje dane. trochę podobnie jest np. w systemie plików btrfs - tam też możesz zrobić snapshot w czasie O(1) i nie powoduje on nagłego zwiększenia zajętości miejsca na dysku.

tu nie ma miejsca na wiarę czy niewiarę. wystarczy sprawdzić co czym jest.

jeśli chcesz wyjaśnienie działania gita od kogoś innego niż zwykłego forumowicza to zapraszam na blog firmy github: https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/ . wydaje mi się, że znają się dobrze na gicie.

precyzując: gitowy commit to snapshot repozytorium + metadane o commicie + hashe parentów (dwa dla merge'a lub jeden dla zwykłego commita)

@Wibowit i teraz masz rację

mustang_ex napisał(a):

precyzując: gitowy commit to snapshot repozytorium + metadane o commicie + hashe parentów (dwa dla merge'a lub jeden dla zwykłego commita)

@Wibowit i teraz masz rację

dobry blef. to jest oczywiste, że commit ma metadane (jak opis, autora czy datę) oraz, że commity tworzą historię commitów zawierającą także merge, ale snapshot repozytorium to główna i najważniejsza część commita. każdy widział te metadane i każdy widział historię commitów. jednak nie każdy wie, że każdy gitowy commit zawiera snapshot repozytorium, a nie śledzi bezpośrednio zmian w plikach (te są wyliczane dynamicznie podczas porównania snapshotów, gdy zachodzi taka potrzeba).

może mam jeszcze doprecyzowywać na każdym kroku, że woda jest mokra, bo inaczej 'nie uwierzysz' we właściwości wody?