Anonymní git clone

3.9.2017 12:21 | Přečteno: 2155× | Za vším hledej Linux | poslední úprava: 3.9.2017 12:25

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.

       

Komentáře

[Josef Kufner]

Pokud máš SSH přístup, můžeš udělat prostý push přes SSH a v post-receive hooku mít update-info. Však ono to v přikladu hooku u každého repozitáře máš:

$ 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-info

Takž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.

[Aleš Kapica]

Právě že dosud jsem používal právě gitolite. Proto mě to zas až tak nepálilo, jenže u gitolite nejsou ty adresáře dostupné pro anonymní klonování přes http, nebo jsem tedy alespoň nikde nenarazil na to jaké se dá použít URL. Všude byly jen odkazy, jak si můžeš stáhnout aktuální obsah jako balík.

Prozkoumat hooky mě nenapadlo, ale stejně bych z toho popisu nebyl zrovna chytrý, protože je mi cizí ta terminologie. Kupř. taková blbost, jako že "bare" repozitář je vlastně ten adresář .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.

[Josef Kufner]

Vystavení repozitářů Gitolite po HTTP je naprosto triviální: Nastavíš webserver, aby hostoval adresář s repozitáři (document root, alias, symlink, cokoliv dle požadované URL).

Viz Pro Git, kapitola Git on the Server - The Protocols. Mimochodem, ta kniha stojí za přečtení celá (a navíc to je oficiální dokumentace Gitu).

Pak to jde ještě po chytrém HTTP, což by mělo být efektivnější a rychlejší, ale to vyžaduje nějaké CGI na serveru – čistý git, gitolite.

[Aleš Kapica]

Tak přesně tohle jsem zkoušel, ale nefungovalo to. A při pouhém porovnání téhož adresáře exportovaného na server přes gitolite a postupem který jsem popsal je zjevné, že tam některé věci nejsou. Ale pochopitelně nemohu vyloučit, že jsem někde něco dělal blbě. Teď už mě to netrápí.

[Luboš Doležel (Doli)]

Díky za zápisek, ani jsem netušil, že jde Git repozitář staticky vystavit přes HTTP bez nějakého chytrého backendu, co by generoval odpovědi pro klienta.

[Martin Mareš]

Jde to, ale pokud klient chce udělat něco jiného než naklonovat úplně všechno (třeba pull do dříve naklonovaného repozitáře), pak je přenos ukrutně neefektivní.

Pro anonymní přístup mi přijde mnohem užitečnější obyčejný git-daemon.

[Pavel Píša]

Jen pro doplnění. Řešení se scp používám pro vystavení na server, kam nemám ssh přístup a nemohu použít žádný jiný systém přes push pull, jak to dělám vžude jinde. Přesto, že je to velký a známý hosting, tak pro upload stránek mnoho nabízeli jen FTP. Později i po mých opakovaných dotazech povolili scp, ale ne shell. Jednalo se o menší repozitář a scp přímo na .git v repositáři jsem nepoužíval, netestoval. Mám další bare repozitory, kam nejdříve udělám lokální push (kromě push na firemní server), pak "git gc" a pak v tom bare zavolám "git update-server-info" a provedu SCP na cílový web. To, že lze vlastně zkopírovat i přímo .git z prascovního repozitáře jsem nezkoušel, řešení to je, ale má nejspíš vadu, že se jako "origin/master" objeví lokální "master" původního repozitáře a ne pushnutý "origin/master", potvrzený master. Takže to, co se scp kopíruje by nemělo asi být přímo z repositáře, kde se provádí vývoj. Měl by být jeden bare repozitář připravený vedle.

[Bedňa]

Fajn ako záloha, ale pre spoluprácu úplne zbytočné, takže to umrie tak či tak.

Hoď to na GitHub a má to šancu prežiť, alebo postav plnohodnotnú alternatívu GitHubu.

To ostatné sú bohužiaľ sny o ničom.

Ak ti na niečom záleží, tak treba to zavesiť na GitHub, pretože tam sú všetci, a všade projekt propaguj, ideálne sú IRC a celkovo komunitné weby. Nechcem sa nejak zviditeľňovať, ale mám pocit, že propagáciou projektu a niekedy dokopanie autora/nového maintainera presídliť na GitHub proste zabralo. To ostatné je len o tom, že všade keď je príležitosť to spomenieš, že taký projekt tu žije.

Videl som ľudí aj z tejto komunity ktorí zareagovali, tak schválne či dá niekto +1 hoci nespomeniem o čo ide :) Neuniklo mi že prispeli.

[ehm]

Myslím si, že GitHub by byl lepší i na „tiché mirrorování“ bez dalšího vývoje. GitHub je obří služba, která pravděpodobně soukromý web server přežije. Taky se to asi snáz dostane do SERPu, nemluvě o tom, že GitHub má vlastní vyhledávač. Procházet soubory nebo historii online bez nutnosti to celé klonovat se taky hodí.

Hledat alternativu má význam spíš pro neveřejné věci (pokud si nechcete na GitHubu platit za soukromý repozitář).

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.

[Bedňa]

Úplný súhlas. Súkromných Git repozitárov sú stovky, ale pokiaľ niekto chce aby sa projekt ujal musí ho dať tam kde chodia vývojári.

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ľ.

[Pavel Píša]

Tak to zásadně nesouhlasím. Historie je extrémně důležitá pro pochopení jak vývojář přemýšlel a dobře vedená historie je často návod, jak přidat nějakou další funkci, která je podobná již dřívějšímu rozšíření. Kam třeba přidat další přepínač, kde ho implementovat, jak byl přidaný export, jak byla provedená úprava na novější verzi knihovny atd.

Co se týče GitHubu, tak souhlasím, když to jen trochu má smysl dát na nějaký veřejný site, kde to lidi napadne hledat. GitHub je co se týče čistého ducha open-source trošku problém, ale pragmaticky i já často toto řešení volím. Dříve jsem především používal SourceForge a stále na něm více projektů spravuji. Ale existují i jiné RMS lépe akceptovatelné alternativy.

ČVUT FEL má i svůj vlastní GitLab, když se jedná o školní věci a server s GitWebem také existuje.

[ehm]

Proboha, zkomprimovat lze celý ten Git repozitář, tedy i s historií.

[Bedňa]

+1

[Aleš Kapica]

Jen o kousek níž máš napsáno proč je komprimování celého git repozitáře kravina.

[Bedňa]

Tak, či tak, pokiaľ chceš aby sa toho niekto chytil, musí to byť vidieť.

[Aleš Kapica]

Nepotřebuji aby se toho někdo chytal. Mě stačí, když můžu někomu napsat: "Jestli to chceš, tak si to naklonuj - tady máš URL …".

[Bedňa]

OK, ale píšeš

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.

[Aleš Kapica]

A z toho vyvozuješ jako co?

Ta věta je zhruba na té samé úrovni, jako kdybych napsal: "Viděl jsem hodně lidí co si nabilo držku na zledovatělém chodníku", v blogpostu, který byl měl za cíl informovat o tom, že se dá zledovatělý chodník také posolit.

[Bedňa]

Keď si ten môj koment prečítaš ešte raz, tak zistíš, že som fakt nepísal nejak opozične, ale reálne ;)

Výhoda napríklad GitHubu je v tom, že si forkneš, potom sa v tom začneš hrabať, pretože ťa niečo trápi a máš ideu že to spraviš. Napr. po dni zistíš, že si na to levý a zájdeš si na IRC o tom pokecať. Čo je výhoda, že máš aktuálnu verziu a forkol si si to keď bug vznikol. Máš tam možnosť sa v zdrojákoch user friendly hrabať, máš možnosť si pekne graficky zobraziť, kto a ako často sa v tom hrabe. Vidíš zas pekne graficky komity a užívateľov a proste bugy, kto ich rieši, kto ignoruje, kto sa ako vyjadruje, je to proste dosť komunitné. A ten fork ti bude trebárs len pripomínať, že toto by bolo dobré doriešiť.

Sám som si v tej komunite nechal napísať opravy, ktoré sú napríklad pre iných užívateľov nepodstatné, alebo ich ani nepostrehli.

Jako zobral som si len výsek z tvojho blogového zápisku, ale hádam som to už osvetlil, čo som chcel povedať.

[Aleš Kapica]

Netřeba nic vysvětlovat. Ještě jednou se podívej na titulek blogpostu. Čteš tam snad něco jako "Jak publikovat git repozitáře přes gitlab". Nebo "Jak nakonfigurovat apache, aby jej bylo možné používat jako git server"? Ne. Takových stránek najdeš mraky. Tenhle blogpost je o tom jak se dá git repozitář publikovat rovnou, pro ty co nechtějí z nějakého důvodu použít gitlab a pod.

[Bedňa]

Goto

[Jendа]

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).

[ehm]

I .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í.

[Aleš Kapica]

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.

[Marián Kyral]

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á.

[ehm]

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á.

[Want]

Nějak ti ušlo, že tady nic k diskuzi není, odpověděl ti už Jenda - udělat čas od času pull je jednodušší než šaškovat s celými archívy.

[ehm]

Až budeš příště měnit přezdívky, dej si alespoň trochu víc záležet, aby to nebylo poznat na první pohled. Já vím, jak se vyjadřuješ, a taky vím, že do práce chodíš brzo ráno a do diskuzí často přispíváš tam.

K Jendovo poznámce jsem se vyjadřoval v komentáři, na který jsi reagoval. Žádnou odpověď jsi neposkytl (ani tam, ani teď), takže to beru tak, že mám pravdu já.

[Aleš Kapica]

Neměním přezdívky. Tohle je také moje přezdívka. Cpe se mi do formuláře když sem lezu i přes telefon - na něm nejsem přihlášený.

[Michal Kubeček]

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.

[ehm]

Může být. Nevýhodou pak je, že bez nainstalovaného Gitu je ten archiv úplně k ničemu – umím si představit, že třeba pro lidi na Windows to může být nepříjemný mezikrok. Ale to asi není případ, který by bylo nutné nějak zohledňovat.

[Aleš Kapica]

Celá tahle diskuze je o gitu a vypublikování repozitáře tak, aby jej bylo možné klonovat přes git. Takže co sem pleteš uživatele, co git nepoužívají. A pokud nechápeš proč to tak někteří chtějí, tak se k té diskuzi raději ani nevyjadřuj. Jsi mimo.

[ehm]

1. Vypublikování read-only repozitáře přes HTTP tak, aby ho šlo klonovat pomocí git clone.
2. ???
3. Profit!

[Jendа]

Centralizovaná služba s de-facto monopolem a debilními ToS. Říkám tomu „vývojářský facebook“ a děkuji, nechci.

[ehm]

V tom nevidím moc argument proti tomu to používat. Možné protiargumenty by byly v zásadě dva:

1. Pod nátlakem vlády by mazaly „protirežimové“ projekty (ala TrueCrypt).
2. Infiltrovali by obsah repozitářů (ať už záměrně, nebo v důsledku bezpečnostní chyby).

První řeší mirrorování ještě někde jinde – ale tam postačuje ten archiv (viz výše). Druhé by byl průser, ale nepřijde mi to u GitHubu o moc pravděpodobnější než u jiného hostingu.

[Jendа]

3. Dáváš americké společnosti neomezenou moc po tobě vymáhat poplatky za americké právníky a bereš si povinnost se za ně soudit.

[ehm]

Budu si ty jejich ToS muset přečíst. To vypadá na dobrou sodu.

[Jendа]

Stačí vyhledat "indemnify".

[Bedňa]

Tiež by som radšej decentralizovaný GitHub, ale o ničom takom neviem.

Poznáš také niečo?

Všetky služby čo poznám sú centralizované a neskutočné sračky. čo ma prekvapilo tak to je Gogs, to je použiteľné, ale zas centralizované.

Registrovať sa na sto web gitoch aby som tam mohol niečo komitovať na to seru a keď je GitHub vývojársky FaceBook, tak to proste berem, slobodná alternatíva zatiaľ neexistuje.

[Salamek]

GitLab je to same co GitHub akorad OSS a muzes spustit na vlastnim serveru... od jiste doby maji cely gitlab nabalickovany, takze staci pridat repo a nainstalovat...

[Josef Kufner]

No... s těma balíčkama to mají tak trochu, aby se neřeklo. Ve skutečnosti ten balíček je image skoro celého systému, který sežere všechnu paměť a upgraduje se půl dne. Ale jinak jo, funguje to.

[Salamek]

Furt lepsi jak provozovat instalaci ze SRC... nedavno jsem migroval z SRC instalace na "omnibus" a ten luxus aktualizace pres APT! To ze to chvili trva (10minut max) je ten nejmenci problem. RAM to zere uctyhodne ale za to se zlepsila odezva oproti SRC installu, pokud to je problem tak by melo jit vse pekne postelovat a pripadne srazit workers etc. v /etc/gitlab/gitlab.rb

[Josef Kufner]

Ono to moc poštelovat nejde. Ten jeden worker si veme půl giga paměti. Provozovat to na něčem s méně jak 4GB paměti je nemožné (měl jsem to tak docela dlouho a není to vůbec hezké).

[Bedňa]

Nefunguje decentralizovane a prepáč, GitLab je hrozná ...

[Josef Kufner]

Ta decentralizace je problém všech webových aplikací a ještě to nikdo slušně nevyřešil.

[Salamek]

LOL, GitLab je super

[Salamek]

Na verejne projekty GitHub, na privatni projekty GitLab na vlastnim serveru... jakakoliv jina kombinace nedava moc smysl...

[Aleš Kapica]

A na vrabce kanón…

[Salamek]

Jasne, 152 privatnich projektu, 45 uzivatelu a 10 skupin... v tom 1653 issues 50 merge requestu 20 snippetu a 3538 poznamek... + napojena installace Mattermost serveru
Kdyz neco delam tak to delam poradne nebo vubec!

[Want]

Pro tebe je to možná hlavní pracovní náplň, ale pro mne zcela okrajová záležitost.

[Vykook]

Smysl to bude mít v případě, že GitLab nahradíš Gogs. Protože na privátní věci fakt nepotřebuješ něco, co žere X GB paměti a asi milion jader CPU.

[Kate]

No, podle jeho komentáře výše to spíš než jako osobní server zní jako privátní server pro skupinu lidí o velikosti středně velké firmy :D

[Vykook]

Ajo, teď na to koukám no otestované to nemám, ale nemyslím, že by to byl pro gogs problém.

[Salamek]

Nevypada to spatne... jen to asi v dobe kdy jsem zacinal s GitLabem jeste neexistovalo
Navic jsem rad ze jsem prezil tu Ruby hruzu a naucil se ten GitLab drzet pri zivote... nepotrebuji to opakovat s Go projektem :)
A hlavne gitlab vyhovuje, naroky na HW me netrapi

[Salamek]

Jo taky mi prijde ze to prehanim ~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

[petr]

Dekuji, libilo se!