Portál AbcLinuxu, 30. dubna 2025 10:33
Nostalgický zápisek o tom, jak bez velkých opičáren pověsit na web git repozitář a umožnit jeho anonymní klonování.
Zanedlouho to bude dvacet let, co jsem začal používat internet a patnáct, co pracuji výhradně na linuxovém desktopu. Za tu dobu jsem potkal mnoho webů i aplikací, a hodně jich už také skončila v nicotě. Nemá smysl polemizovat o tom, jestli to je dobře nebo špatně. Smiřme se s tím, neboť žijeme v době, o které se stejně jednou nebude vědět lautr nic, neboť už teď na mnoha cílových adresách na vás čeká jen kód 404.
Za tu dobu jsem však potkal i několik aplikací, které upadly do zapomění zcela nezaslouženě – jen proto, že vznikly příliš brzy na to, aby našly své uživatele. V lepším případě po nich zůstal alespoň po nějaký čas opuštěný repozitář, než definitivně zmizel.
Dnes se považuje téměř za standard, že se při vývoji používá git. Ale není to zase tak dávno, co se prosadil. Před rokem 2000 kralovalo cvs než ho z pomyslného trůnu začalo vytlačovat svn. Jeho vývoj začal r. 2000 a v době, kdy jsem začal používat výhradně linuxový desktop (2003), na něj teprve začínali vývojáři zvolna přecházet. Jenže použitý koncept se mi vůbec nelíbil. Proč bych měl pro každou verzi udržovat kopii celého stromu?
Podobně se na věc zřejmě díval i Linus Torvalds, protože místo něj – i přes nelibost skalních zastánců open source – začal r. 2002 používat proprietární verzovací systém Bitkeeper. Jenže r. 2005 došlo na slova kritiků jeho rozhodnutí, když společnost BitMover Inc., co tento verzovací systém vyvíjela, přestala poskytovat bezplatnou licenci, která se vztahovala na vývoj open source projektů. Jelikož v té době stále nebylo nic lepšího na výběr, začal Linus psát verzovací systém vlastní - git.
Už si ani nepamatuji, kdy jsem ho poprvé zkoušel každopádně již r. 2007 jsem byl přesvědčen, že právě to je verzovací systém, kterému patří budoucnost, a tak jej každému doporučoval. Bazaar, jehož vývoj začal také r. 2005 se mi totiž od počátku jevil jako mrtvě narozené dítě, protože vycházel z svn. Mercurial, jehož vývoj začal zhruba v tutéž dobu jako vývoj gitu, nepřinášel oproti gitu nic lepšího. Nebyl tak rozšířený a bylo jasné, že zůstane na okraji zájmu. A ještě méně rozšířený byl darcs, se kterým jsem se setkal na škole.
Jak vidno, paleta verzovacích systémů s nimiž se člověk mohl setkat, po r. 2005 byla docela pestrá, takže první krok který jsem u aplikací kde mě zajímal postup vývoje dělal, byla konverze jejich zdrojáků do gitu. U většiny z nich vývojáři sami časem přešli na git, ovšem jak dopadly ty, které původní vývojář již dávno opustil? Po většině z nich dnes nenajdete ani stopu.
Některé přežily jen díky tomu, že byly převedeny do gitu, tak jak jsem to dělával já, a umístěny na web, odkud si je lze naklonovat a případně pokračovat v jejich vývoji. Triviální věc – pro ty co vědí jak ji udělat.
Dlouho jsem to neřešil, protože jsem pro publikování svých věcí používal školní server, kde jsem měl rozjetý gitweb, ale štvalo mě to, protože jsem tušil, že je to zcela prosté, jen jsem nějak nemohl z té hromady protichůdných informací na webu vydolovat co je k tomu zapotřebí udělat. Většinou ty stránky stereotypně odkazují k tomu, abyste si založili účet na github.com a nebo popisují, jak to rozjet na vlastním serveru – přes CGI. Jenže nic z toho jsem nechtěl. Nechtěl jsem si zakládat účet na nějakém cizím serveru, když mám vlastní. Nechtěl jsem si rozjíždět nějaký vlastní github a nechtěl jsem na svém serveru povolit CGI skripty, když to jinak nemám zapotřebí. Chtěl jsem jenom umístit git repozitář tak, aby si ho mohl naklonovat i někdo jiný. Nic víc.
Když jsem zkusil git repozitář jen tak jak byl nakopírovat do adresáře co byl přístupný přes web, a na něj zkoušel udělat akci clone, tak jsem končil v logu s touto hláškou:
server:80 172.0.0.1 - - [01/Sep/2017:08:03:09 +0200] "GET /app.git/info/refs?service=git-upload-pack HTTP/1.1" 404 475 "-" "git/2.13.2"
Až mi nakonec poradil Pavel Píša, zběhlejší uživatel gitu než jsem já. A řešení je, jak už to tak bývá, stupidně prosté:
cd repo-aplikace git update-server-info scp -r .git server:/var/www/cesta/app.git
A pokud je váš www server dostupný z webu, může každý anonymní uživatel udělat:
git clone http://server/cesta/app.git
Pochopitelně je třeba mít pořešené aby démon, pod kterým běží webový server, měl do cílového adresáře přístup. Ovšem to už je pouhá prkotina.
Tiskni
Sdílej:
$ git init $ cat .git/hooks/post-update.sample
#!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, rename this file to "post-update". exec git update-server-infoTakže po SSH uděláš push a hook ti rovnou aktualizuje potřebná metadata pro HTTP přístup. Nic víc netřeba a takto to původně bylo zamýšleno autory Gitu. Pak příšel Gitolite. Založí se jeden společný unixový účet pro všechny repositáře a podle SSH klíče použitého k přihlásení se Gitolite rozhoduje, zda přístup povolí, či nikoliv. Nemá žádné GUI, je to jen pár hooků v Gitu a SSH. V principu je to stejné, jako předchozí přístup, jen trochu pružnější (obzvlášť při spolupráci více lidí). Repozitáře jsou stále obyčejné bare repositáře, které můžeš vystavit na webu. Mají jen nastaveno pár hooků. Gitolite také umí snadno zakládat repozitáře při prvním push na neexistující adresu a lze ho používat i bez dedikovaného unixového účtu. Na jednoduché hostování repozitářů je to velmi praktické. Github, Gitlab a podobné jsou jen hezčí webové nadstavby nad tím samým principem, který používá Gitolite. Pokud to chceš vystavovat na statický web (a tedy nechceš ty hezká webová prohlížítka), určitě bych při pushi vygeneroval nějaký přehled, co tam zrovna je – výpis větví, tagů a kousek nedávné historie. Hodí se to pro kontrolu, zda je tam to, co si myslíš, že tam je.
3.9.2017 12:46
.git, ve kterém jsou nasázeny soubory gitu. Kdyby o něm takhle nemluvil Pavel, když mi ukazoval jak na to, tak bych na to i teď čuměl jako puk. Jak už jsem zmínil, i když používám git dlouho, nejsem zase tak zběhlý uživatel, protože jen málokdy potřebuji dělat nějaké složitější operace.
Ono na hodně věcí může přijít člověk sám, ale na všechno ne. Sám na sobě jsem mohl pozorovat, jak raketově jsem šel nahoru když jsem nastoupil na ÚMOb Ostrava-Jih. A to jen proto, že jsem se měl koho ptát. Ovšem zanedlouho jsem se dostal do stadia, kdy už jsem se neměl koho ptát. Naštěstí jsem změnil práci a opět další raketový vzestup. Naštěstí na VŠ je stále se koho na co ptát – to je důvod proč se nehrnu do komerční sféry. Tam nikdo nemá čas na to aby se s někým bavil o věcech, které jsou zrovna mimo to co dělá. Sice je to také přínosné, ale jen po určitý čas a do určité míry. A to ještě musíte mít takové štěstí, jako jsem měl já, že natrefíte na člověka, kterému není zatěžko věnovat svůj drahocený čas, aby vás k něčemu zajímavému a prespektivnímu nasměroval.
3.9.2017 12:52
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
4.9.2017 00:05
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
git vůbec žádný přínos.
4.9.2017 01:06
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
A konečně – pokud bych se GitHubu chtěl přecejen vyhnout, aby byl OSS trochu víc decentralizovaný, tak by bylo lepší to celé hodit do jednoho zkomprimovaného archivu. Na read-only repozitáři nemá klonování přes git vůbec žádný přínos.Presne, medzi GIT repozitárom read only a ZIPom nieje rozdieľ.
4.9.2017 08:54
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
4.9.2017 11:37
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
4.9.2017 12:56
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Za tu dobu jsem však potkal i několik aplikací, které upadly do zapomění zcela nezaslouženě – jen proto, že vznikly příliš brzy na to, aby našly své uživatele. V lepším případě po nich zůstal alespoň po nějaký čas opuštěný repozitář, než definitivně zmizel.na tom serveri sa určite dočkajú slávy, uznania a rozšíria sa v komunite. Nechcem haniť žiadnu snahu o záchranu nejakých slobodných projektov, ale toto im nijak nepomôže, jedine tak zázrakom.
4.9.2017 18:20
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
4.9.2017 03:00
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Na read-only repozitáři nemá klonování přes git vůbec žádný přínos.Do archivu release nebo i .git? Pokud to první, tak je to horší v tom, že nevidím jednotlivé commity, nemůžu bisectovat chyby a release se typicky vydává málo často; pokud to druhé, tak je opruz updatování (musím - typicky ručně - stáhnout celý archiv, zatímco git pull pouze automaticky stáhne změny).
.git/. Updatování by se tady nejspíš nekonalo, pokud se bavíme o mirrorování discontinued projektů. I kdyby ten projekt pořád žil, většinou si budeš pullovat primárně od hlavního maintainera. Mirror by přišel na řadu až jako poslední.
Updatování by se tady nejspíš nekonalo, pokud se bavíme o mirrorování discontinued projektů. I kdyby ten projekt pořád žil, většinou si budeš pullovat primárně od hlavního maintainera. Mirror by přišel na řadu až jako poslední.Než jsem ten zápisek publikoval, tak jsem ho notně ořezal, protože to byla jenom omáčka k tomu jak umožnit klonování git repozitáře. I tak je to docela dlouhý zápisek. Ale jak vidím, některým by asi prospělo, kdyby si ji přečetli. Takže… Ač se to zdá k nevíře, jsou vývojáři co při své práci dodnes nepoužívají žádný verzovací systém. Osobně to považuji za zhovadilost, ale chápu, že pečlivé ukládání změn do jednotlivých commitů vyžaduje značnou vnitřní disciplínu, kterou sám nemám. Nicméně snažím se alespoň čas od času uložit do gitu aktuální stav, než něco rozvrtám. Obvykle je totiž situace (alespoň u mne) taková, že rozvrtám jednu věc, kvůli ní musím upravit jinou a pak další, atd. atd. To si člověk říká, dodělám to, ať to není v gitu rozbité. Jenže mezitím přijdou důležitější úkolu, které se musí řešit, A nakonec, když se k tomu zase po čase dostanu je z toho jedna velká hromada změn, s popiskem - "Aktualizováno". Ovšem pořád je to lepší než nic. A pak – kdo by se chtěl chlubit svým chaotickým způsobem programování, že? Není lepší veřejně publikovat jen stavy, které lze považovat za použitelné? Celá historie gitu by nezasvěcené bez řádného dokumentování commitů jen mátla, protože by neměli ponětí, proč něco zrovna nefunguje. Pak jsou aplikace, které sice mají svého maintainera, ale ten je dlouhodobě neaktivní. Z nejrůznějších důvodů. No a pak se objeví (v lepším případě) fork, ve kterém jsou změny, které autor ani dostatečně neotestoval, ale sračky padají na původního autora. S projekty na github a pod. je spojená i hromada byrokracie na kterou nemám čas ani náladu, případně to má i další háčky a zádrhele, o kterých nikdo jiný nemusí vědět. Já chci mít svoje věci u sebe, na svém serveru. Svoje projekty si programuji primárně pro sebe a nemám zapotřebí aby mi do toho někdo paralelně hrabal. Jestli chceš, tak si to naklonuj, vrtej si do toho sám a pokud to uznáš za vhodné, pošli mi patch mailem nebo si to dej kam chceš. Já změny přidám až si najdu čas na to aby zkontroloval, jestli se mi tím něco nerozbije.
4.9.2017 21:12
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Obvykle je totiž situace (alespoň u mne) taková, že rozvrtám jednu věc, kvůli ní musím upravit jinou a pak další, atd. atd. To si člověk říká, dodělám to, ať to není v gitu rozbité. Jenže mezitím přijdou důležitější úkolu, které se musí řešit, A nakonec, když se k tomu zase po čase dostanu je z toho jedna velká hromada změn, s popiskem - "Aktualizováno". Ovšem pořád je to lepší než nic. A pak – kdo by se chtěl chlubit svým chaotickým způsobem programování, že? Není lepší veřejně publikovat jen stavy, které lze považovat za použitelné? Celá historie gitu by nezasvěcené bez řádného dokumentování commitů jen mátla, protože by neměli ponětí, proč něco zrovna nefunguje.Na to existuje taková šikovná věc, jmenuje se to větve
Před tím, než to rozvrtám, tak si vytvořím novou větev, tam se v tom hrabu, commituji dle potřeby. Hlavní větev se nerozbije a že nebude fungovat vývojová větev se přece dá očekávat 
No a když vývoj úspěšně skončí, tak jej nahraji do hlavní větve. Podstatná výhoda je, že během tohoto procesu nemusím zachovat kompletní historii vývojové větve, ale můžu provést revizi, některé commity sloučit, u jiných upravit popis. Všechno tak, aby to dávalo smysl a historie byla dostatečně popisná.
I tak je to docela dlouhý zápisek. Ale jak vidím, některým by asi prospělo, kdyby si ji přečetli.Já jsem ji („tu zápisku“) četl. Otázku, v čem je klonování pomocí
git clone výhodnější než stažení archivu, to neodpovídá. Proč to provozovat přes HTTP už vůbec ne.
Následující elaborát o tom, že někdo Git nepoužívá vůbec, tak ty ho používáš alespoň naprosto prasácky, je vskutku dojemný, ale na žádné diskutované otázky to taky neodpovídá.
I .git/.
Pokud je cílem někde vystavit zaarchivovaný repozitář k downloadu, tak bych spíš řekl "jen .git/" (resp. bare repository). Vycheckoutovaný snapshot jen zbytečně nafoukne archiv a vytvořit ho je otázka jednoho příkazu.
4.9.2017 02:57
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.9.2017 05:37
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.9.2017 09:07
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
4.9.2017 18:00
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
no otestované to nemám, ale nemyslím, že by to byl pro gogs problém.
~146 projektu jsou z toho primo moje co jsem delal ja Zbytek jsou spolecne + privatni kamose
Uzivatele jsou vetsinou klienti at muzou hlasit issues + lidi co delali na jednom privatnim projektu spolecne...
Myslim ze tak ~20 projektu bych mohl s klidem smazat protoze jsou vydane jako OSS nebo deprecated, ale dokud nezacne dochazet misto na 2TiB RAID10 poli tak me to moc netrapi
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
4.9.2017 16:00
6.9.2017 22:16