GitMagic (8) – nedostatky Gitu
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama

GitMagic (8) – nedostatky GituGitMagic (8) – nedostatky Gitu

 

GitMagic (8) – nedostatky Gitu

Google       Google       1. 7. 2009       10 910×

Přestože je Git tak skvělým pomocníkem a hezky napsaným kusem programu, všechno má i své mouchy. Git není výjimkou.

Reklama
Reklama

Je tu pár problémů, které vymetu zpod koberce. Některé mohou být vyřešeny pomocí různých skriptů a kliček, některé vyžadují přeorganizování či předefinování projektu a kvůli některým zbývajícím otravnostem si bude muset jeden prostě počkat. Nebo lépe sám pomoci!

Slabosti SHA1

Jak čas postupuje, kryptologové odhalují více a více slabostí SHA1. Již nyní je pro dobře financované společnosti proveditelné najít kolize. Během pár let bude moci snad i normální osobní počítač mít tolik výpočetní síly, aby potichu poškodil Gití repozitář.

Doufejme, že Git přejde na lepší hashovací funkci předtím, než výzkum zničí SHA1.

Microsoft Windows

Provozovat Git na Microsoft Windows může být těžkopádné:

  • Cygwin, linuxové prostředí pro Windows obsahuje Windowsí port Gitu.
  • MSys Git je alternativa požadující minimální nároky na běhovou podporu, i když některé příkazy potřebují ještě propracovat.

Nesouvisející soubory

Pokud je váš projekt velký a obsahuje mnoho nesouvisejících souborů, které jsou neustále měněny, Git může být mnohem více znevýhodněn než ostatní systémy, protože soubory nejsou sledovány jednotlivě. Git sleduje změny na celém projektu, což je povětšinou prospěšné.

Řešením je rozdělit projekt na části, kde každá sestává ze souvisejících souborů. Jestliže chcete, aby bylo vše stále v jednom repozitáři, podívejte se na git submodule.

Kdo co mění?

Některé verzovací systémy vás nutí, abyste výslovně označili nějakou cestou soubor předtím, než ho začnete upravovat. Přestože je toto zvláště otravné, protože to vyžaduje komunikaci s centrálním serverem, má to dvě výhody:

  1. Diffy jsou rychlé, protože musí být prověřeny jenom označené soubory .
  2. Člověk může objevit, kdo další pracuje na souboru, tím, že se zeptá centrálního serveru, kdo ho označil pro úpravu.

S odpovídajícím skriptováním můžete docílit toho samého s Gitem. Vyžaduje to spolupráci od programátora, který by měl spustit příslušný skript, když začne upravovat soubor.

Historie souboru

Jelikož Git zaznamenává změny celého projektu, vybudovat historii jediného souboru vyžaduje více práce než ve verzovacích systémech, které sledují soubory individuálně.

Zpomalení je to malé a vyplatí se v porovnání s tím, že ostatní operace jsou úžasně rychlé. Například git checkout je rychlejší než cp -a a změny celého projektu (delty) jsou na zkomprimování lepší než balík změn souborů.

Počáteční klonování

Když má projekt bohatou historii, vytvořit klon je mnohem náročnější, než stáhnout kód poslední revize v jiných verzovacích systémech.

Počáteční „náklady“ jsou ale dobré „zaplacení“ v dlouhodobější perspektivě, protože většina budoucích operací bude rychlá a offline. Nicméně v některých situacích může být lepší vytvořit jen mělký klon pomocí volby --depth. Výstupní klon má omezenou funkčnost, ale je to mnohem rychlejší.

Nestálé projekty

Git byl napsán, aby byl rychlý vzhledem k velikosti změn. Lidé dělají malé změny z verze na verzi. Jednořádková oprava chyby sem, nová funkce tam, zlepšení komentářů a tak podobně. Ale když jsou vaše soubory radikálně jiné v navazujících revizích, pak každým commitem historie nutně roste s velikostí celého projektu.

Není zde nic, co by s tím mohl jakýkoli verzovací systém udělat, ale normální uživatelé Gitu budou trpět více, poněvadž se normálně kopíruje celá historie.

Měli byste přezkoumat důvody tak velkých změn. Možná zauvažovat o změně formátu souborů. Málo významné změny by měly pouze způsobit malé úpravy nejvíce na pár souborech.

Možná že hledáte databázi nebo zálohovací/ar­chivační řešení, ne verzovací systém. Například verzování může být nevhodné pro správu opakovaně pořizovaných fotek z webkamery.

Pokud musí být soubory neustále měněny a opravdu musí být verzované, je zde možnost používat Git centralizovaně. Jeden pak vytváří mělké klony, které si stahují pouze kousek historie projektu. Samozřejmě že mnoho Gitích nástrojů pak nebude přístupno a opravy musí být posílány jako patche. Ale toto je pravděpodobně v pořádku, protože není jasné, proč by někdo chtěl historii takto nestálých souborů.

Dalším příkladem je projekt závisející na firmwaru, který má podobu velkého binárního souboru. Historie firmwaru uživatele nezajímá a aktualizace se špatně komprimují, tudíž revize by zbytečně vystřelily velikost repozitáře kamsi k výšinám.

V tomto případě by měl být zdrojový kód uložen v Gitím repozitáři a binární soubor někde odděleně. K ulehčení života byste mohli distribuovat skript, který použije Git k naklonování kódu a rsync nebo Gití mělký klon pro firmware.

Globální počítadlo

Některé centralizované systémy obhospodařují celé kladné číslo, které se zvětšuje, když je přijat nový commit. Git ukazuje na změny podle jejich hashe, což je v mnoha případech lepší.

Ale někteří lidé mají rádi, když tam někde to číslo je. Naštěstí je jednoduché si napsat skript, který s každou aktualizací v centrálním repozitáři zvětší číslo, pravděpodobně tag, a přidá ho k hashi posledního commitu.

Každý klon může mít takové počítadlo, ale to bude pravděpodobně zbytečné, protože počítadlo centrálního repozitáře je rozhodující pro všechny.

Prázdné podadresáře

Prázdné podadresáře nemohou být sledovány. Vyřešit to můžete vytvořením „hloupých“ souborů.

Spíše než design je momentální implementace to, co bychom měli vinit za tento nedostatek. Jak vznikne na Git větší tlak, více uživatelů začne volat po této vlastnosti, a tak bude implementována.

Počáteční commit

Stereotypní počítačoví vědci počítají od 0 radši než od 1. Bohužel, vzhledem ke commitům, Git se nedrží této konvence. Mnoho příkazů je nepřátelských před počátečním commitem. Navíc s pár mezními případy musí být zacházeno speciálně, jako například rebase s rozdílnými počátečními commity.

Gitu by prospělo definovat nulový commit: hned, jak je repozitář vytvořen, by se HEAD nastavila na řetězec obsahující 20 nulových bytů. Tento speciální commit by zastupoval prázdný strom bez jakéhokoli rodiče, který by předcházel všechny Gití repozitáře.

Potom by spuštění git log místo skončení s fatální chybou informovalo o tom, že ještě nebyly provedeny žádné commity. Podobně pro ostatní nástroje.

Každý počáteční commit je bezpodmínečně potomek tohoto nultého commitu. Například rebase nesouvisející větve by způsobilo její naroubování na cíl. Nyní jsou všechny commity krom počátečního aplikovány, což vyústí v slučovací konflikt. Jedním řešením je použít git checkout následovaný git commit -C na počáteční commit a potom udělat rebase ostatního.

Bohužel jsou tu i horší případy. Když je slučováno několik větví s rozdílnými počátečními commity, výsledek rebase vyžaduje velké ruční zásahy.

Tento článek je překladem osmé a poslední kapitoly – Git Shortcomings – z GitMagic od Bena Lynna.

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

1 názor  —  1 nový  
Hlasování bylo ukončeno    
0 hlasů
Google
(fotka) Jakub KulhanAutor momentálně studuje na osmiletém gymnáziu v Kralupech nad Vltavou. Programování se věnuje od 11 let, kdy ho poprvé uchvátila možnost "mít vlastní stránky". Nakrátko poté objevil PHP a už se to s ním "vezlo". Webové aplikace zůstaly jeho hlavní doménou, ale ve svém volném čase probádává nejrůznější zákoutí světa programování, programovacích jazyků a všeho kolem nich.
Web    

Nové články

Obrázek ke článku Hackerský kongres přiveze v září do Prahy špičky světové kryptoanarchie

Hackerský kongres přiveze v září do Prahy špičky světové kryptoanarchie

Hackerský kongres HCPP16 pořádá od 30. září do 2. října nezisková organizace Paralelní Polis již potřetí, a to ve stejnojmenném bitcoinovém prostoru v pražských Holešovicích. Letos přiveze na třídenní konferenci přes 40 většinou zahraničních speakerů – lídrů z oblastí technologií, decentralizované ekonomiky, politických umění a aktivismu. Náměty jejich přednášek budou také hacking, kryptoměny, věda, svoboda nebo kryptoanarchie.

Reklama
Reklama
Obrázek ke článku ICT PRO školení zaměřené nejenom na ICT

ICT PRO školení zaměřené nejenom na ICT

Dovolte, abychom se představili. Jsme zaměstnanci společnosti ICT Pro, profesionálové v oblasti poskytování komplexních ICT služeb. Neboli služeb spojených s informačními a komunikačními technologiemi, které dnes - ve 21. století - tvoří  nedílnou součást běžného provozu všech moderních firem.

loadingtransparent (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();
Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý