Rozdělení Git repositáře na menší kusy II

Proč nemá každá nette extrasa a podobně samostatný repozitář? Vůbec nerozumím té snaze něco někam zašívat.

Ten apigen bych určitě nechal v samostatném repozitáři. Je to univerzální nástroj, při vhodném marketingovém postupu jistě snadno proslavitelný, který bude lidi zajímat víc než nette-build-tools.

3. 4. Skus tie libky nalinkovat cez filesystem. GIT to pozna a do repo sa ulozi pomerne zrozumitelna informacia. (neviem ale ako sa to chova na NTFS a pri pouziti relativnych symlinkov).

Editoval srigi (19. 10. 2010 20:40)

@kravčo Prave preto som pisal o relativnom symlinku :)

Stiahol som si balíček zo stránky, všetko pekne pokope…

Rozbalím, používam, prídem na tieto tri drobné veci:

• preklep v doc komentári niekde v Nette
• preklep v prípone šablóny v sandboxe
• super príklad na použitie formulára, ktorý by sa hodil medzi príklady

Na to aby som ich poslal dobrou cestou, zrazu potrebujem forknúť tri repozitáre, naklonovať ich upraviť, samostatne pushnúť a poslať tri pull requesty (ibaže to ide ľahšie a ja o tom neviem). Nabudúce už nemusím forkovať ani klonovať, zbytok ostáva…

Verím, že rozdelenie pomohlo tomu, aby mohol byť na svojom mieste aktuálny nette.js, či v skeletone priamo framework (a neviem čo ešte), otázkou je, či toto má byť riešené na úrovni SCM a nie až v balíčku na stiahnutie (kde je to samozrejme pomerne triviálne). Nehovorím, že nie, to vieš asi lepšie ty sám (pretože s tým pracuješ temer denno-denne, na rozdiel, nech nechodím ďaleko, napríklad odo mňa)…

Snažím sa len poukázať na to, čo mňa osobne trochu rozčúlilo (a môže odradiť iných).

vadí mi struktura repozitáře nette/nette

když klonuji tak se vždy vytvoří automaticky složka, to je výhoda, na druhou stranu je to takové „best practise“ mít v archivu složku (při použití tlačítka download)

osobně by mi vyhovovalo kdyby se obsah adresáře Nette přesunul do rootu repozitáře, stejně je všechno ve složkách a proto by tam ty texťáky ani nevadily…

jinak mi to v ničem nevadí, je to přímočařejší pokud něco hledám

změny zachovat +1 (popř. doladit, teď si ale nevybavím, která drobnost mi trošičku vadila :)

Ahoj, posílám pár svých poznámek a postřehů. Možná budou trochu z jiného pohledu, ale i tak věřím, že někomu mohou pomoci.

Osobně jsem se napoprvé se submoduly trápil. Přecházel jsem na git ze svn a byl jsem lehce rozčarovaný z toho, jak git submoduly fungují, oproti svn externals. Soudě podle toho, že jsme v dubnu v Mediu od submodulů odešli (po týdením používání), jsem asi nebyl sám. Štvalo nás hlavně to, že submoduly nepřinesly žádné usnadnění práce, právě naopak, člověk kolikrát commitoval 2× častěji.

Nicméně, během několika měsíců jsme nenašli lepší způsob jak submoduly nahradit, takže jsme se k nim nyní vrátili a snažíme se s nimi lépe sžít. Proč to vlastně děláme? Chceme mít v rámci aplikací jasno, jaké verze knihoven třetích stran používáme. Pokud mám aplikační repositář, tak možnosti jsou vesměs tři (opravte mě, pokud jsem na nějakou zapomněl):

Nakopírovat knihovnu natvrdo do repositáře

Tohle je docela prasečina. Pokud to udělám, tak si nikdy nemohu být jistý, jakou verzi knihovny používám. Mohu si verzi sice někde poznamenat, ale věřte tomu. A navíc, líný (což prý znamená dobrý:)) programátor si to stejně nebude časem poznamenávat.

Dát do repositáře link na očekávaný adresář někde nahoře

Tohle také není moc dobré. Repositář nebude fungovat out-of-the-box. Navíc nasazovat takovýhle repositář na serveru, kde mám aplikaci jako klon aplikačního repositáře je dobré peklo. Zvlášť, když poběží na několika serverech. Abych aplikaci rozjel, musím ručně postahovat knihovny a dát je na správné místo, případně nalinkovat do repositáře příslušné adresáře. A to na každém serveru zvlášť.

Použít submoduly

Prozatím nejpříjemnější varianta, kterou znám. Mám vždy jasno, jakou verzi knihovny používám. Pro rozběhnutí aplikace stačí naklonování repositáře (plus inicializace submodulů). Varianta navíc lze obohatit symlinkama v rámci samotného repositáře (jak psal Nilp). Pokud to neudělám, vznikne mi například v cestě k Nette „libs/Nette/Nette/…“. Ano, estét nad tím rozhodně nejásá, robot loader s tím ale problém nemá.

Další postřehy ke git submodule

Nyní ještě něco ke git submodulům obecně. Ano, je pravda, že pokud submodulu něco změním a chci novou verzi submodulu použít v repositáři, který submodul používá, musím v něm udělat jeden commit, který bude spočívat v aktulizaci hashe (ukazatele) na revizi submodulu. To se mi z počátku zdálo jako velká brzda v práci se submoduly. Nyní už mi to tak strašné nepřijde a navíc to opravdu dává smysl. Možná jsem si ale prostě zvykl.

Tím ale sranda nekončí. Pokud mám v týmu parťáka, který pracuje na té samé aplikaci, já posunu revizi submodulu vpřed, pushnu změny, které si on pullne, tak to ještě neznamená, že se mu automaticky posunul vpřed jeho submodul. Submodul mu zůstal ve stejné revizi jako před byl pullnutím, nezávisle na tom, že já jsem ho posunul dál. Pro to, aby submodul dostal na aktuální revizi, musím udělat git submodule update. Na první pohled možná nelogické (a určitě nepříjemné, protože to musím řešit), na druhý pohled ale asi správná věc. Kdyby se submoduly automaticky po pullnutí posunuly vpřed, pravděpodobně by to nadělalo více neplechy než užitku.

Zároveň nemusí být na první pohled jasné, proč mám po naklonování repositáře repositář bez submodulů. Abych si submoduly načetl, musím udělat git submodule init a následně git submodule update. A co když mám submodul, který obsahuje další submoduly? git submodule init se totiž nedá zavolat rekurzivně (git submodule update by to měl umět). Musím tak inicializaci provádět v každém submodulu a nořit se hlouběji a hlouběji. V začátku to tedy může být otrava, ale zase mám kontrolu nad tím, jak hluboko si klon udělám.

O tom, že se do submodulu nedá dát podadresář nějakého repositáře se už psalo. Je to nešikovné, ale podle toho co jsem četl by to nešlo jednoduše naprogramovat, takže Linus prohlásil, že to nebude. Ostatně v menuálu gitu je na prvním řádku napsáno „git – the stupid content tracker“. Dá se to obejít filtrováním, ale to je docela drsné řešení a navíc se zbavím možnosti pracovat se submodulem jako s normálním repositářem.

Bohužel, nejsem s Nette natolik sžitý, abych mohl napsat něco jiného. Nette je pro mne jenom jedna z knihoven, kterou mám v repositáři, nepracuji ani se skeletonem, ani s examples a podobně, takže se možná trochu míjím. Původně jsem chtěl mít možnost naklonovat si čistě knihovny, jenže s adresářovou strukturou, kterou Nette má se tomu jednomu Nette adresáři navíc nevyhnu. A separovat testy by byl IMHO velký krok zpět. I tak jsem ale rád, že na serveru (a i u sebe na localhostu) nebudu mít v aplikaci různé nepotřebné věci pro její běh.

Aktualizace: Tak mi kolega právě řekl, že existují parametry git submodule update –init –recursive. Počáteční inicializace všech submodulů se tak dá provést rekurzivně na jedno zavolání.

Editoval VeN (21. 10. 2010 14:56)