Názory k článku Git po dvaceti letech: změny přijdou pomalu

Vsechno hezke, ale kdy konecne mergneme IPv6 do produkce?

Git IPv6 umí. Tohle spíš směřuje na GitHub ne? Což tedy taky nechápu, už několik let tvrdí, že brzo.

To je právě tím, jak zkratkovitě a divně jsou tyto výpisky z Patrickovy přednášky udělané. Doporučuju původní přednášku. Je to sice delší a vyžaduje to plnou pozornost ("nedá se u toho žehlit"), ale stojí to za to, protože to pak začne všechno dávat smysl.

na to bych mohl odpovedet treba takhle :-) https://dnschecker.org/#AAAA/gitlab.com

Co je tohle za posedlost? V čem budu mít lepší git repozitáře, když je budu posílat po v6, namísto v4? Proč bych si něčeho takového měl proboha vůbec v souvislosti s verzováním kódu všimnout? (ignorujme nižší jednotky IPv6 influencerů, kteří se zde často (pravděpodobně lživě) naparují, že si v4 natvrdo sami vypnuli...)

8. 9. 2026, 11:12 editováno autorem komentáře

Já mám třeba část infrastruktury pouze na IPv6, protože například nechci platit příplatek za přidělování IPv4 adres. V tom případě je pro mě dost podstatné, že jsou všechny důležité zdroje dostupné po šestce, protože se k nim jinak nedostanu. V takové situaci je jednoduše GitHub ze hry.

Ufff, tomuto nerozumiem. GitHub ako sluzba na internete na ktoru sa potrebujete dostat nevyzaduje verejnu adresu. Nerozumiem aky problem sa riesi. Ak velmi potrebujete mozte mat predsa verejnu IPv6 a neverejnu IPv4. Co som nepochopil?

Myslim, ze Petr mysli ruzne VPS apod. Ktere provozuje ciste ipv6 only - nejsem si jist - jak casto nabizi moznost pro IPv4 konektivitu pouzit NAT

Služba na internetu, na kterou se potřebuji dostat, vyžaduje veřejnou IP adresu. Bez ní se nemám k čemu připojit.

A konkrétně GitHub? Třeba mám IPv6-only VPS (nechci připlácet za IPv4 adresu) a potřebuju na něm mít aktualizované git repository hostované na GitHubu. Nebo na něj chci stáhnout aplikaci, jejíž distribuční balíček je hostovaný na GitHubu. Nebo na něm chci spouštět GitHub Action worker. Ve všech případech mám smůlu, protože z IPv6-only zařízení se na GitHub nedostanu.

"Ufff, tomuto nerozumiem."

To je dost videt ...

"GitHub ako sluzba na internete na ktoru sa potrebujete dostat nevyzaduje verejnu adresu"

Pokud nekdo provozuje IPv6 only, tek NECHCE provozovat NATy, ani zadny jiny jeste uchylnejsi mechanismy. Jednoduse proto, ze to znamena administraovat vsechno 2x, a cokoli bez nativni konektivity znamena vyrazne slozitejsi konfiguraci, mnohem nachylnejsi k rozbiti a chybam.

Čo ak mám napríklad súkromný IPv6-only maven repozitár, a chcem ho použiť z GH Action? Môžem sa ísť tak akurát poje***.

N druhej strane, síce nepodporujú IPv6 ale aspoň majú dobrý uptime. Oh wait...

u GitHubu omezuje per ipv4 limit napr uzivatele NixOS za natem. da se to obejit skrz ucet s tokenem ale mnohem vic by davalo smysl mit soucasny komunikacni protokoly.

Při ceně IPv4 je to zcela normální posedlost. Neřeším domácí uživatele ale servery.

Pokud chcete podobné články, vezměte AI, ale nějakou hodně levnou, a dejte jí prompt "udělej mi výpisky z Patrickovy přednášky na FOSDEM 2026. Ať je tam toho co nejvíc, srozumitelnost stranou, pointu na závěr nepotřebuju - ať je tvoje odpověď levnější".

https://archive.fosdem.org/2026/schedule/event/HTJK33-evolving_git_for_the_next_decade/

Pardon, ale to fakt nešlo vydržet. Pamatuju si, že už pod jiným "článkem" stejného autora byla debata, jestli to píše on nebo AI ("vim a AI"). Proč to otevírám znova? Protože se nic nezměnilo! Popravdě, je mi jako čtenáři úplně jedno, jestli ten AI styl plodí sám nebo dá jeden prompt do AI a vydává to za svou práci. Důležitý je výsledek a ten je, jaký je: odpovídá promptu naznačenému na začátku mého příspěvku.

Moc se omlouvám, že zase komentuji, ale po prvním odstavci jsem se zarazil - to je AI! A taky že jo. Zase stejný "autor", který pravidelně lepí svoje jméno k AI textu.

Místo českých vět jen divně šroubované konstrukce.

"Linus .. popsal motivaci přímo" - popsal "přímo"?? co to je?
"..mají identitu odvozenou od obsahu" - jak jako "odvozenou identitu"?
"Index se hodí při pečlivém skládání commitů" - "pečlivém"??
atd.

Já tohle nechci číst. Slova jsou poskládaná za sebe, ale není to česky. Je to AI slop. Ať si "autor" alespoň zaplatí nějaký kvalitnější model a dá si trošku práci s promptem. Tohle je urážka čtenářů.

Zvlášť ten závěr vyžaduje to protáhnout dalším AI, aby z toho vyházelo přebytečný balast. Takové korporátní...

BTW AI slop na AI slop zde https://grok.com/share/c2hhcmQtMi1jb3B5_ce984070-beaf-4ddf-96e8-507e2f15afa0

8. 9. 2026, 13:25 editováno autorem komentáře

Také mne některé věci praštily do očí, že to nese silnou stopu AI. Je mi jedno, jestli autor použije AI. Ale když mne to vytrhne ze čtení a říkám si: „tohle je nějaké divné,“ a vzápětí mi to dojde: „tohle vypadá jako napsané AI“, vadí mi to.

U tohohle článku mne napadlo, že by bylo zajímavé udělat tipovačku. Vybrat pár úryvků a nechat lidi tipovat, zda to psal člověk, AI nebo to napsal člověk s výraznou redakcí od AI.

git je jako hasteriva zenska, z jakekoliv blbosti udela konflikt

Zmíněné Jujutsu už nějaký ten pátek používám pro osobní projekty, a je to super.

180 milionů vývojářů - to je 18 Českých republik naplněných jen vývojáři, je možné, tolik?

Nějaký tip jak manageovat sub-modules? Jde mi hlavně o to ušetřit čas stahování z internetu a také ušetřit místo na disku. Mám naklonovaných několik na sobě nezávislých repozitářů, všechny mají LLVM jako sub-module. LLVM je "velký jako kráva". Takže bych chtěl LLVM stáhnout z internetu pouze 1x a pak ... použít work-tree, nebo "něco", prostě abych to nemusel celý stahovat znovu, a abych to neměl na disku 4x. To samé boost, je to malý repozitář, který má asi 130 sub-modules. Chtěl bych naklonovat všech 130 repozitářů zvlášť, a pak je "nějak" podstrčit boostu a dalším jiným repozitářům aniž bych je musel klonovat znovu. Zkoušel jsem bare repo plus work-tree, ale to mi úplně nezafungovalo, teď zkouším sym-link/junction na adresář 'objects'.

to mi prijde jako ukazkovy priklad pro pouziti fs s deduplikaci.

De-duplikace ti nepomůže, když máš jedno repo 10x na disku a do každého fetch-uješ zvlášť. Musíš z internetu stahovat 10x tolik dat. Konsolidace objektů do pack-ů proběhne v každém repu trochu jinak, de-duplikace to nepozná.

ja mam zkusenost s ZFS deduplikaci a to je proste podle bloku dat, myslel jsem, ze vetsina jich bude stejnejch i po kompresi. (velkej boost vs malej tvuj projekt jak moc to asi zmeni slovniky?). treba to funguje i na isa ruznejch distro, coz bych cekal ze je podobny. nemyslis deduplikaci podle souboru? to by podle mne fungovalo hur. na jakym FS jsi tu deduplikaci zkousel pro zajimavost?

Taky by se mi to hodilo. Mám hromadu worktrees, které si sdílejí lokální větve. Ale každý ten worktree má submoduly zvlášť. Takže lokální větve v submodulu musím synchronizovat přes origin.
Jsou to malé věci, ale pomohlo by to

Možná jsem příliš konzervativní, ale jak si tak čtu to množství změn co všechno bude potřeba upravit v dalších projektech tak by mě dávalo smysl nechat současný git tak jak je a gitu 3.0 dát jiné jméno než git.

Ušetřil by se zmatek v tom jaký projekt co používá a falešné očekávání kompatibility. Navíc by se nový git (s novým jménem) nemusel tolik zabývat a ohýbat pokusem o zpětnou kompatibilitou.

To by bylo to nejhorší, co by se mohlo Gitu stát. Třeba Python měl s tímhle postupem velký problém, Perl to prakticky nepřežil. Vzhledem k tomu, jak Linux dbá na zpětnou kompatibilitu u Linuxu (což je pravděpodobně jeden z důvodů, proč je Linux tak rozšířený), nedovedu si představit, že by něco takového dopustil u Gitu. Jasně, dnes už Git nevyvíjí, ale předpokládám, že kdyby řekl, že směr, kterým se Git chce ubírat, je nesmysl, byl by vyslyšen. A nebo by prostě forknul původní Git.

Ano i ne. Perl nepřežil jiné věci než tohle. Tohle byl spíš ten poslední problém. A Python s tím měl problém proto, že rozhodně ne každý má za to, že Python 3 je lepší než Python 2. Teda ne, že by to v dnešní době nebylo už celkem jedno ale dřív to relevantní bylo.

Ale hlavně: gitový repozitář není programovací jazyk. To se vůbec nedá srovnávat. Pokud zvládnete migraci dat, v podstatě můžete přejít lusknutím prstu. Zdrojáky se ještě dost nedávno migrovaly dost špatně a ani dnes to není zrovna triviální a někdy ani levné.

10. 9. 2026, 13:30 editováno autorem komentáře

Našťastie stačí cursoru povedať čo potrebujem dosiahnuť a on vykoná správne git príkazy :)

urcite. Takto se kolegovi podarilo (neprimo - pres AI) vykonat git add --all a ve verejnem PR se objevily klice, certifikaty a dalsi zajimavosti ;)

To ovšem byla chyba, že nebyly v .gitignore. Pokud to závisí na tom, že si každý vzpomene, které soubory má z přidání do Gitu vyloučit, dříve nebo později na to někdo zapomene. Navíc to nijak nesouvisí s AI – ten kolegy by to nejspíš udělal úplně stejně podle návodu na StackOverflow nebo v diskusi na Root.cz.

zejo, taky me to prekvapilo, ze si to nehodil do .gitignore. Proste spec-driven coding...

"Našťastie stačí cursoru povedať"
A kontrolujes co ten cursor dela? Nebo jsi sebevrah.

jasné, push robím vždy sám. Jednoducho veci ako zlúč commity do jedného a pripoj k inému branchu s popisom zmien voči nemu to spraví 100x rýchlejšie než by som to spravil sám, lebo nepotrebujem to každý deň, takže to nenosím v hlave. Ručne som už tiež spravil chyby, čo som musel opravovať, takto sa mi to ešte nestalo

Proč se neuchytil místo GITu Mercurial? I dnes je Mercurial hodně okrajovou záležitostí....

Nebo svn ktere mam moc rad.

Proč? Vždyť to vždycky byla věc, o které se dalo maximálně říct "není to tak strašné jako cvs".

Svn je strašný. Jakmile člověk nedělá sám a nebo potřebuje větve, tak nemá skoro co nabídnout. Já běžně používám Git jenom lokálně.

Prave ze kdyz clovek nedela sam je svn lepsi. Protoze v nem nevznikaji konflikty jako v gitu. Vetve? svn ma co nabidnout.

Konfliktů naopak v SVN vzniká víc, protože má SVN horší algoritmus mergování než Git.

Řekl bych kvůli GitHub a kvůli tomu, že Git používá Linux a tak to nemůže být špatné. Java (OpenJDK) resp. Oracle nakonec migrovali z Mercurial na Git. Používá se ještě vůbec někde?

Firefox, i kdyz koukam ze taky prechazi na Git.

Hlavní je uvědomit si časovou osu - Linus začal psát git v době, kdy Mercurial ještě nebyl.
Někde jsem četl, že kdyby už Mercurial existoval, tak ho použije a nedělal by git

A že se git uchytil víc je jak adaptací v linuxovém světě, tak pak příchodem github a podobných platforem