Git submodule alternatywa?

Question

Mam kilka pracujących drzew z pewnymi zależnościami. AFAIK, git modułem wymusi następujące:

• mieć kopię każdego drzewa roboczego (Slave) w podkatalogu każdym drzewie roboczym używając go (master)
• repozytorium mistrz powiela wszystkie informacje z niewolników

Nie mam nic przeciwko tym, że repo robi się większe, ale posiadanie kopii jest dla mnie nie do przyjęcia. Zmusiłoby mnie to do reorganizacji wszystkich projektów, aby kopia była połączona. Co więcej, edycja niewłaściwego pliku może łatwo doprowadzić do zamieszania.

Mam inny pomysł:

• Each sklepów mistrzowskie listę wszystkich swoich niewolników.
• Nie są wymagane żadne inne informacje w systemie głównym.
• Przy każdym zatwierdzeniu w master, tworzone jest "snapshot-commit" w slave.
• "Migawka-zatwierdzenie" jest migawką bieżącego stanu roboczego drzewa, ignoruje bieżący stan indeksu (używam już "migawki-zatwierdzenia" przed odrzuceniem niektórych niezamówionych zmian).
• "Migawka-zatwierdzenia" zbiera się w oddziale, którego nazwa pochodzi od imienia i nazwiska głównego. Komunikat zatwierdzenia zawiera wartość mieszania głównego zatwierdzenia. (IMHO, to jest lepsze niż zalanie tysiącami tagów.)
• Kasa działa jak zwykle, chyba że wymagana jest rekursja na niewolników.

Jedyny problem widzę są następujące:

• W commity w niewolników będzie gromadzić i nigdy nie zostaną usunięte, nawet jeśli pan popełnia już nie istnieją.
• Zobowiązania w systemie głównym nie zawierają się samodzielnie, można usunąć zatwierdzenie skierowane w systemie głównym. Ale nie widzę żadnej szansy, żeby to mogło się stać przypadkiem, więc mogę z tym żyć.
• Nie mogę sobie wyobrazić, w jaki sposób inne polecenia git mogłyby to poprzeć. Ale znowu mogę z tym żyć.

Pytam, czy ktoś już to zaimplementował (lub jeśli to zły pomysł).

Answer 1

Nie jestem pewien, czy śledzę cię od momentu, gdy repozytorium dla rodziców (twój "mistrz") zawiera tylko odniesienie do ścisłego SHA1 modułu częściowego (sub-repo sprawdzone w ramach repozytorium macierzystego).
Nie ma to wpływu na wielkość repozytorium nadrzędnego.

Wartość subtree merge strategy (better managed though git subtree) zwiększyłaby rozmiar repozytorium nadrzędnego, ale ta (poddrzewo) nie jest tym, o czym mówisz.

Inną alternatywą dla submodułu byłaby wersja git-slave (gits), która jest nieco podobna do implementacji.

Answer 2

Myślę, że to zły pomysł, ponieważ jest dziwny i zabierze cię z obsługiwanej ścieżki dla wielu rzeczy.

Najpierw wyjaśnienie: Podczas korzystania z submodułów repozytorium "master" (referencyjne) nie staje się znacznie większe. Przechowuje tylko referencję do repozytorium (prawdopodobnie URL) i identyfikator zatwierdzenia. Ale to nie wydaje się być tutaj najważniejszą kwestią.

Gdy mamy do czynienia z problemem, jak to istnieją trzy zasadzie 3 ścieżki można zejść:

1. umieścić wszystko w jednym repozytorium. Czy przekonałeś się 10 razy, że naprawdę musisz rozdzielić te rzeczy? Pamiętaj, że możesz zacząć od jednego repo i podzielić je później. Pamiętaj też, że git merges faktycznie działa, więc rywalizacja dewelopera nie jest tak dużym problemem.

2. Użyj zewnętrznego systemu zarządzania pakietami. Git NIE jest i nie udaje, że jest menedżerem pakietów. Szanse są dobre, że platforma, której używasz, ma menedżera pakietów obsługującego bardziej złożone sytuacje zależności. Maven, rubygems, npm, nuget ... jest ich wiele.

3. Użyj submodułów "zamontowanych" w podkatalogach.

Zasadniczo, podmoduły powinny być twoim ostatnim wyborem, gdy masz do czynienia z własnym kodem. Świetnie radzą sobie z bibliotekami stron trzecich, ale w końcu są królewskim bólem dla własnego kodu. Dodaj do tego skomplikowane rozwiązanie, które proponujesz, a po prostu nie będzie zabawnie pracować.