Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Na začátku je nutné se zmínit o dvou aspektech publikace Pro Git. První je, že ji autor uvolnil pod licencí Creative Commons. Druhý je, že její, řekněme zdrojový kód, je umístěn v git repozitáři na github.com. A to rovněž inspirovalo CZ.NIC k vydání českého překladu, který je rovněž dostupný na stránce Edice CZ.NIC. Vzhledem k otevřenému charakteru knihy není překvapivé, že mimo PDF s českým překladem je možné prolistovat veřejně dostupnou verzi.
Kniha je rozdělena do devíti kapitol, které jsou logicky členěné a postupují ve shodě s Komenským – od jednoduššího ke složitějšímu.
První, úvodní kapitola začíná zvolna, to jest představením konceptu verzování, věnuje se lokálním, centrálním a především distribuovaným systémům pro správu verzí. Po tomto lehkém terminologickém úvodu jsou představeny základní principy systému git – snímky objektů, lokální charakter operací a rovněž oblast připravených změn (staging area, známá rovněž jako index). To vše je doprovázeno přehlednými ilustracemi. Po té následuje oddechové téma instalace a kapitola končí popisem základní konfigurace. A to vše na pouhých deseti stranách, což dává tušit, že zbytek bude informacemi doslova přetékat.
Hned první věta této kapitoly zní: „Pokud jste ochotní přečíst si o systému git jen jednu kapitolu, měla by to být právě tahle.“ A přestože by byla škoda minimálně třetí kapitoly o větvení, je tomu skutečně tak.
Od úvodního oddechového tématu inicializace a klonování repozitáře se kniha přesune na sledování stavu souborů. Podrobně jsou zde vysvětleny příkazy git add a především všechny možnosti příkazů git status a git diff, které jsou, vzhledem k existenci oblasti připravených změn, bohatší na různé možnosti a přepínače, než je obvyklé. Malou vsuvku dostane i soubor .gitignore a poté se text vrátí k zapisování revizí – příkazu git commit. Rozebráno je též mazání a přesouvání souborů, které je v systému git mírně specifické (totiž implicitní).
Velká část textu se pak zabývá zobrazení historie revizí příkazem git log, jehož možnosti jsou skutečně košaté. Není bez zajímavosti, že manuálová stránka git-log.1.gz je druhá největší – větší je už jen git-config.1.gz, a to především pro množství parametrů, které popisuje. Představeny jsou nejrůznější parametry jako -p, který do historie revizí přidává patche, nebo --stat, přidávající výstup z diffstat. Dále se autor věnuje pokročilým možnostem formátování, v čemž je git log skutečně velice tvárný. A „historická“ část kapitoly končí stručným představením grafického gitk.
Rušení – to je téma následujících stránek. Představen je příkaz pro přepsání poslední revize git commit -amend. A dále i git reset, který ruší soubor z oblasti připravených změn a git checkout, který mimo jiné vrátí stav souboru z poslední revize. Tím se vyčerpaly všechny základní lokální příkazy, které musí uživatel systému git znát, a text se přesunuje do vzdálených končin.
Přesněji řečeno do vzdálených repozitářů. Nejprve je vysvětlen jejich koncept a poté všechny příkazy pro jejich správu. Tedy git clone přidávající origin, git remote pro jejich prohlížení, přidávání a rušení, git push pro odesílání lokálních změn. A nakonec i dvojice příkazů git fetch a git pull pro stažení změn ze vzdáleného repozitáře. Autor se tu chytře jejich rozdíly nezabývá a čtenáře odkazuje na kapitolu 3 o větvení.
Kapitola končí popisem značek v systému git, rozdíly mezi prostou a anotovanou značkou, jak vytvořit podepsanou značku a jak je sdílet s ostatními příkazem git push. Na samotný závěr autor opět zařadil drobet git config a představení doplňování příkazů a parametrů.
Někteří lidé mluví o větvení v systému git jako o jeho exkluzivní funkci, zní věta z úvodního textu k této kapitole. A jak jsem naznačil v předchozím textu, byla by velká škoda skončit u druhé kapitoly a používat git jen jako složitější svn či jiný vcs, protože dle mého je větvení skutečně ta zabijácká vlastnost.
Autor se zpočátku vrací do první kapitoly a připomíná, jak systém git ukládá a strukturuje objekty (blob, strom, revize). Poté teprve prozradí, že větev v systému git je pouze ukazatel na poslední revizi, takže změna větve znamená pouze přepnutí tohoto ukazatele jinam. To dělá z větví v systému git extrémně nenáročnou operaci, tudíž spousta uživatelů inklinuje k tvorbě mnoha větví. Ale zpět ke knize, ke slovu se dostávají příkazy git branch a git checkout, který byl krátce představen v předchozí kapitole, a koncept souboru HEAD. Stav stromu systému git po každém příkazu je přehledně ilustrován, takže opravdu důkladnému pochopení toho, co se děje uvnitř, nebrání čtenáři vůbec nic.
Po jednoduchém vytváření a přepínání větví následuje rozdělení historie, tedy kdy ve stejném bodě historie následuje v každé větvi jiná revize. A pochopitelně jejich slučování příkazem git merge, které je v systému git až neskutečně snadné, vzhledem k tomu, že je systém schopen najít společného předka revizí sám. Autor toto téma zpracoval opravdu důkladně, takže čtenář má v libovolném okamžiku detailní přehled o stavu stromu. Vysvětleny jsou rozdíly mezi sloučením rychle vpřed (fast forward) a rekurzivním, včetně dopadu na historii. A dále i řešení konfliktů při slučování a podporu různých nástrojů pro slučování změn.
Poté se text vrací k tématice větví – jsou představeny další možnosti git branch a různé způsoby jejich využití – pro oddělení stabilního a vývojového kódu, přes tematické větve pro vyvíjené vlastnosti. Další velké téma jsou vzdálené větve, které jsou obvykle velice podrobně popsány a dojde i na rozdíly mezi příkazy git push a git fetch a poté dojde na přeskládávání.
Příkaz git rebase představuje další možnost, jak slučovat změny v systému git. Autor nejprve ilustruje samotný příkaz a poté ho využije pro sloučení tematické větve do větve master, přičemž výsledek vypadá jako lineární hitorie. Po této triviální operaci následuje ukázka přeskládání při složitejší konfiguraci větví. Závěr kapitoly působí jako varování pro nezvedené vývojáře, kteří by toužili přeskládat již zveřejněnou historii – autor zde ukazuje důsledky takového nerozumného počínání.
Kapitola (nejen) pro administrátory serverů je spíše odpočinková záležitost pro čtenáře, kteří čtou knihu postupně a nehodlají spravovat server. Po mnoha informacích o používání systému git jako programátor se tato kapitola zabývá stranou serveru, což je činnost, se kterou se většina uživatelů potýkat nemusí. Autor to zmiňuje hned v úvodu a netrpělivé čtenáře odkazuje na konec této kapitoly, která se zabývá nastavením hostovaného účtu.
Ale pěkně od začátku. Kapitola začíná vysvětlením čtyř (respektive pěti, pokud jste ochotni považovat file:// za odlišný protokol) základních protokolů, které systém git podporuje – local, ssh, git a http. Autor zběžně představí každý protokol, jeho výhody i nevýhody a pak už se věnuje tématu – jak umístit repozitář systému git na server pomocí git init --bare, případně git clone --bare. Následující část je spíše rychlopříručkou správy uživatelů unixového serveru a nastavení ssh klíčů a serveru Apache, nicméně bez těchto znalostí není možné git na serveru fakticky používat. Autor probírá mnoho řešení, jako například přidávání každého uživatele zvlášť nebo používání sdíleného uživatele git nebo seznamuje čtenáře s git-shell, který coby přihlašovací interpret příkazů umožňuje uživateli používat výhradně příkazy systému git. Věnuje se též nastavení virtuálních serverů Apache pro anonymní přístup k repozitáři pomocí protokolu http a seznamuje se základní vizualizací stromu v prohlížeči pomocí cgi skriptu gitweb.
Další obsáhlá tématika se týká pokročilých metod přidělování přístupových práv pomocí projektu Gitois, který umožňuje definovat jemnější přístupová práva než „všichni mají přístup pro čtení i zápis“. Zajímavostí je technické řešení, protože Gitois je speciální git repozitář, který obsahuje vlastní nastavení oprávnění. Jako ještě mocnější nástroj na definici nejrůznějších smyslných i nesmyslných politik přístupu potom autor uvádí Gitolite, který umí to samé, a navíc umí definovat pravidla pro jednotlivé reference (větve či značky) a vytvořit tak naprosto zabijáckou politiku. Mně osobně přišly oba nástroje trochu jako kanón na vrabce, nepřinášející nic, co by nešlo zařídit pomocí oddělených stromů, které se navíc běžně (a snadno) používají.
Po Gitois a Gitolite se téma vrací k přeci jen využitelnější věci – nastavení git démona. Myslím, že mohu prozradit, že důvodem existence takového démona je umožnit rychlý anonymní přístup k repozitáři, což protokoly ssh (není anonymní) ani http (není rychlý) neumí. Konec kapitoly je věnován git hostingům, i když se pozornost soustředí výhradně na autorův domovský github.com, který je rozebrán skutečně podrobně. Zájemci o ostatní hostingy jsou odkázání pouze na seznam na git wiki.
Pátá kapitola se nese ve znamení postupů, kterak využít distribuovaný potenciál systému git a jakými způsoby je možné organizovat práci na projektu. Autor stručně popíše centralizovaný postup (nijak odlišný od CVS a SVN), postup s integračním manažerem, případně jeho variantu pro opravdu velmi velké věci – postup diktátor a poručíci, který je variantou druhého, pouze s několika úrovněmi integračních manažerů. Opravdu velmi velká věc je například Linux.
Základem kvalitní spolupráce pomocí systému git jsou kvalitní revize, protože ty jsou to, oč tu běží. Autor proto uvedl několik rad pro zlepšení jejich kvality od git diff --check pro kontrolu zlobivých bílých znaků, git add --patch pro zapisování změn z jednoho souboru v několika revizích až po rady, jak psát zprávy k revizím.
Další část kapitoly se věnuje různým scénářům spolupráce mezi vývojáři. Popis je ve formě opravdu podrobné ilustrace toho, co se děje s historií stromu a jakým způsobem začleňovat změny ostatních a pochopitelně i svoje. Pokud chcete systému git skutečně porozumnět, neměli byste tuto část přeskočit. Naopak si ji podrobně přečíst a pochopit.
Následující část se věnuje tak trochu netypickému způsobu spolupráce (alespoň vzhledem k ostatním systémům verzování) – posílání patchů pomocí emailu, což je ovšem v systému git plně podporovaný způsob práce, takže git format-patch, git send-email umožní spolupráci i v případě, že má přispěvatel pouze anonymní přístup pro čtení (a email, pochopitelně). Čímž odpadají všechny nudné věci se zakládáním veřejně přístupného stromu, případně přidáváním oprávnění.
Ovšem nejen vytvářením patchů živ jest člověk. Občas se dostanete i na opačnou stranu a nějaký ten patch musíte aplikovat. Na řadu tak přichází příkazy git apply a git am (v případě, že je patch uložen v mailboxu). Autor ukazuje nejen ideální svět čistě aplikovaných patchů, ale i co dělat, když se věci nedaří. Pro větší změny, případně trvalejší spolupráci si vývojáři zakládají svoje stromy či větve, v nichž dělají svoji práci, kterou jednou za čas navrhnou k začlenění. V dalším textu si tedy zopakujete, jak si vzdálenou větev přidat a stáhnout pomocí git remote add a git fetch. Dále pak jak zjistit změny přidané autorem dané větve od rozdělení větví, jak změny přijmout pomocí sloučení, přeskládání nebo vyzobání (cherry-picking). To vše opět doplněné detailními ilustracemi historie repozitáře.
Konec kapitoly ukazuje, jak uložit a pojmenovat veřejný gpg klíč přímo do vašeho stromu systému git, příkaz git describe pro popis význačných revizí a příkazy git archive a git shortlog vydatně pomáhající při vydávání verze vašeho projektu veřejnosti.
Šestá kapitola tvoří předěl – do této doby byly popisovány především aspekty, s nimiž se uživatel běžně setkává. Tato kapitola je všehochuť vlastností, které mohou, ale nemusí být váš denní chleba.
První část rozebírá revize, respektive všechny myslitelné způsoby, jak revize identifikovat, od prosté a zkrácené SHA-1 hodnoty (včetně výletu do říše pravděpodobnosti při odpovědi na otázku, co se stane, když budou mít dvě revize stejný otisk). Dále ukazuje, jak pomocí příkazu git show zjistit, které větvi odpovídá daná revize, nebo opačně pomocí git rev-parse zjistit SHA-1 číslo větve. Následuje git reflog, který ukládá všechny pozice HEAD ve všech větví vašeho stromu, takže se znalostí tohoto příkazu je prakticky nemožné se ztratit tak, aby se nešlo vrátit do příčetného stavu. Dále se vysvětlují reference dle původu, čili znaky ~ a ^ a jejich přesný význam. Obvykle nás nezajímají jednotlivé revize, ale intervaly od-do. Git podporuje i tuto možnost, takže autor ukazuje, jak je možné získat přehled revizí v zadaném intervalu a zobrazovat tak rozdíly mezi větvemi.
Následující téma je interaktivní příprava k zapsání – git add --interactive. Příkaz dokáže vybrat z provedených změn pouze část a tu připravit k zapsání v oblasti připravených změn. Autor tu zevrubně popisuje možnosti tohoto příkazu.
Odložení změn je další ne zcela běžně využívaný koncept. Problém, na který mnozí při používání systému git narazí, je to, že git nedovolí přepnout větev, pokud jsou v aktuálním adresáři nezapsané změny. To může nezkušené vývojáře přivést k frustraci ze zbytečných revizí, případně až k přechodu tam, kde jsou větve prosté podadresáře. Autor popisuje řešení – příkaz git stash, což je zásobník změn, do něhož je možné práci uložit a vyčistit si tak pracovní adresář. Pochopitelně je popsán i zbytek, tedy jak odložené změny zase aplikovat a jak řešit konflikty.
Falšování historie je následující velké téma. Jednou z klíčových (a kontroverzních) vlastností systému git je, že nijak nebrání modifikaci celé historie stromu a dokonce má nástroje, které to umí zařídit. Autor popisuje git commit -amend pro změnu předchozí revize a především švýcarský nůž pro změny historie – git rebase --interactive, kterým můžete historii přeskládat prakticky libovolným způsobem. Pokud jsem označil interaktivní přeskládání za švýcarský nůž, pak git filter-branch popisovaný dále je motorová pila bezohledně přepisující celou dosavadní historii stromu. Autor uvádí příklady z praxe: opravdové odstranění souboru, změna emailové adresy nebo povýšení podadresáře na nový kořenový adresář (typicky třeba trunk při importu z nejmenovaného konkurenčního systému).
Následující část se jmenuje trochu nelogicky ladění v systému git a zabývá se podporou tohoto systému při hledání chyb. Autor ukáže anotace git blame, včetně exkluzivní možnosti anotovat i části přesunuté z jiných souborů a binární vyhledávání příkaz git bisect, který urychluje nalezení té ošklivé revize způsobující regrese v kódu.
Poslední téma šesté kapitoly je jak spravovat v jednom stromě nezávislé projekty – typicky jde o hlavní program a knihovnu. Git podporuje takzvané submoduly, což jsou speciální objekty ve stromě, které obsahují nezávislé stromy. Autor toto téma zpracovává opravdu podrobně, i když se nemohu zbavit dojmu, že toto je oblast systému git, kde jsou (a hlavně koušou) lvi. Na konci kapitoly proto uvádí alternativní strategii pomocí začlenění podstromu příkazem git read-tree.
Sedmá kapitola se zabývá rozličnými způsoby uzpůsobení systému git nejrůznějším uživatelským potřebám.
Začíná příkazem git config, odkud vlastně čte nastavení a rozdíly mezi systémovým (--system), uživatelským (--global) a lokálním nastavením. Následuje popis nejrůznějších nastavení na straně klienta, včetně barviček, stránkovače nebo třeba nástroje pro slučování. Následuje výčet možností konfigurace serveru jako zapnutí kontrol konzistence, povolení pouze revizí rychle vpřed nebo zakázání mazání vzdálených revizí.
Dalším tématem jsou atributy, což jsou nastavení týkající se obvykle určité části projektu (adresáře nebo souborů) – autor ukazuje, jak systému git říct, aby některé soubory bral jako binární, jak nastavit speciální diff pro určitý typ souborů, jak provést expanzi klíčového slova ve styl CVS/SVN nebo jak modifikovat soubory před zapsáním revize, jak ignorovat určité soubory při vytváření archívu nebo jak nastavit odlišné strategie slučování pro některé soubory.
Háčky jsou následující téma – pomocí nich je možné spouštět skripty na základě nějaké akce. Autor seznamuje s háčky na straně klienta a serveru, ukazuje, jak si vynutit správné formátování zpráv k revizím nebo jak implementovat vlastní ACL, a to vše pomocí příkladů napsaných v Ruby.
Svět není dokonalý. Většinou není možné okamžitě přepnout každý projekt, se kterým přijdete do styku, na systém git. Tak začíná kapitola o tom, jak přejít z jiného systému na git, případně jak alespoň používat git lokálně a nechat ostatní se trápit s jejich nemožně zastaralým systémem.
První část kapitoly se věnuje modulu git svn, který umožňuje oba dva režimy práce. Autor podrobně rozebírá jednotlivé kroky a příkazy používané při práci oproti vzdálenému SVN serveru. Od počátečního „checkoutu“ git svn clone přes odevzdávání změn pomocí git svn dcommit a pro uživatele svn trochu kryptický git svn rebase, který je rovněž podrobně popsán. Autor sice důrazně varuje před pokusy o vytváření nelineární historie, kterou SVN nerad, ale k problému se postavil čelem a ukazuje možnosti, jak kombinovat větve systému svn a git. Zbytek svn části se věnuje ekvivalentům příkazů svn log|blame|info a jiným.
V dalším textu autor ukazuje, jak stávající systém zahodit a pokračovat ve vývoji pomocí systému git. Takže ukazuje, jak git svn clone doplnit o mapování uživatelů do formy používané v systému git, čímž se vyčistí historie, a jak převést SVN značky a větve na lokální značky a větve. Tím dostaneme historii a strukturu značek k nerozeznání od stavu, kdyby byl software vyvíjen systémem git od začátku.
Následuje obdobný příklad pro import ze systému Perforce a především je podstatná část kapitoly věnována psaní vlastního importéru pomocí příkazu git-fast-import. Autor podrobně ukazuje, jak napsat importér ze struktury verzovaných adresářů.
Původní název „Elementární principy systému git“ je sice méně úderný, přesto stejně popisný – na řadě jsou detaily fungování systému git.
Autor začíná honosnou definicí – git je obsahově adresovatelný systém souborů s uživatelským rozhraním VCS (version control system) na svém vrcholu (první část definice pochází přímo od Linuse, druhá ne, protože v tehdejší době neměl git s verzovacím systémem zase tolik společného). Autor nejprve stručně pohovoří o tom, že v dávných dobách (tedy před 1.5) nebylo uživatelské rozhraní tak příjemné jako dnes – naopak bylo trochu neohrabané a řekněme to rovnou nízkoúrovňové (plumbing). Jaký to rozdíl od dnešních vysokoúrovňových (porcelain) příkazů. Jedním z příjemných důsledků tohoto „toolkit design“ je fakt, že git svoje vnitřnosti nijak neskrývá.
Autor v této kapitole rozebírá spousty příkazů a opravdu detailně rozebírá objekty systému git, jejich typy, příkazy pro jejich manipulaci, věnuje se referencím, balíčkovým souborům pro úsporu místa, ukazuje refspec – mapování vzdálených a lokálních větví. Významnou částí je podrobný popis přenosových protokolů, kde čtenář zjistí, proč je hloupý protokol tak pomalý. Poslední velké téma této kapitoly je správa a obnova dat, tedy přímá manipulace s již existujícím systémem. Zmíněn je tu reflog, který je užitečný, pokud přepneme HEAD do některé z předchozích revizí, příkaz git fsck pro hledání objektů, na něž chybí reference, a jak použít filter-branch pro smazání souboru z celé historie stromu.
Kniha Pro Git je skutečně skvělá. Informačně nabitá, přehledně strukturovaná a pokrývající prakticky vše potřebné. Její podtitul by mohl znít – vše, co jste chtěli o systému git vědět, a ještě mnohem více. A pokud něco převyšuje množství obsažených informací, tak je to skutečnost, že je většina podrobně rozepsána včetně vysvětlení a tam, kde je to třeba, i doplněna přehlednými ilustracemi. Autor nenechá čtenáře příliš tápat. Jedinou mojí výhradou je autorova přílišná fascinace jazykem Ruby, jehož použití nebylo vždycky ku prospěchu věci a výklad spíše komplikovalo. V knize jsou též drobné ostré hrany typu – po doporučení používat slovesa v infinitivu ve zprávách k revizím je následující zpráva v minulém čase, ale kvalitě celku to nikterak neubírá.
Český překlad je docela povedený – sympatické je, že se autor snažil držet výhradně českých termínů, takže kniha není plná brančí a merdžování, ale větví a slučování. Jedinou výhradu bych měl k příliš husté sazbě – text zaplňuje prakticky celou stránku a nenechává mnoho prostoru na okrajích. Rovněž jsem marně hledal jméno překladatele, které bývá zvykem uvádět.
Tuto knihu tedy vřele doporučuji všem, kdo se chtějí o systému git dozvědět více – jak naprostým začátečníkům v oblasti verzování, tak znalým uživatelům jiných systémů, ale i relativně zkušeným uživatelům systému git, kteří v knize najdou jednak vysvětlení jejich často „magických“ postupů a rovněž řadu zajímavých informací o netušených možnostech.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
10.3.2010 09:07
Petr Bravenec | skóre: 43
| blog: Bravenec
10.3.2010 10:29
Nicky726 | skóre: 56
| blog: Nicky726
Na začátku je se nutné zmínit o dvou aspektech publikace Pro Git.Mnohem víc česky by podle mě bylo: Na začátku je nutné se zmínit o dvou...
Pro mě byla kniha Pro Git výrazný mezník v používání a porozumění gitu. Jako snad jediná totiž ukazuje to, co ostatní dokumentace často zamlčovala, obzvlášť ta původní: PROČ je to celé vymyšlené zrovna takto a JAKÝ je tedy způsob práce s tím. V tom je kniha, i díky skvělým ilustracím (v elektronické formě navíc barevné), naprosto nedostižná. Kapitola o vnitřnostech gitu (devátá) pak čtenáři připomene jeho dřívější pátrání v manuálových stránkách nebo jiných příručkách o gitu - akorát, že když to čte člověk po přečtení kapitol 2 a 3, tak už najednou chápe - a zpětně tak chápe i to, co četl o gitu dříve.
Jestli různé informace o gitu z jiné dokumentace tvoří mozaiku, tahle kniha je lepidlo té mozaiky a se spoustou náhradních dílů navíc, kdyby se vám náhodou z minula ztratily nebo čistě jen pro pohodlí, že tady je máte na jednom místě. Ale to nejdůležitější je to lepidlo.
Navíc tím, že je kniha veřejná a svobodná, lze ji dále rozšiřovat a upřesňovat a přispět může každý. Já už mám rozvržený příspěvek o vypořádání se s rebase ve vzdáleném repozitáři, jen ho dotáhnout (obzvlášť angličtinu)
Za chybu CZ.NIC pak považuji, že tento princip nepodpořili a že jejich překlad není v repozitáři knihy. Takže se na něm nedá pokračovat dále. (Je tam jiný překlad do češtiny.) V knize není ani uvedeno jméno překladatele, natož kontakt na něj. A na webu nic.cz člověk nenajde odkaz na knihy jinak než vyhledávačem. Myslím, že CZ.NIC by v tomto ohledu měl na své (jinak moc symatické) snaze ještě zapracovat.
Co se týče obsahu knihy samotné, jedinou chybou může někomu připadat hustota informace a nároky na čtenářovo pochopení (obzvlášť pokud není odchován školou typu matfyz). Opravdu člověk nemůže čekat, že při prvním čtení "dá" 60 stránek za večer, v posteli před usnutím. Odměna za zvýšené úsilí je ale sladká.
10.3.2010 20:54
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Pdf je super, ale dokud se neobjeví kvalitní a cenově dostupný e-book reader, tak si ve vlaku moc nepočtu. A jindy není čas.
11.3.2010 21:56
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
13.3.2010 23:15
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Navíc taková čtečka vydrží dlouho na jedno nabití a e-ink se lépe čte a vyřešilo by mi to problém s knihami na dovolené. Tahat sebou NB se mi jednak nechce a navíc v kabinovém zavazadle už by na něj nezbylo místo. Tam mám zrcadlovku a objektivy. Ale čtečka by se mi tam ještě vešla.
27.8.2011 22:44
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
11.3.2010 20:34