Názory k článku
Čtvrtý důvod proč zvolit Git : Úpravy a opravy historie

Super článek. Díky.

Souhlas. Že se dá rebase použít tímhle způsobem, jsem opravdu netušil :-)

Tak on se dá použít i jinak. Např. když chcete vybrat nějaké commity z jiné větvě, a nechce se vám psát git cherry-pick… git cherry-pick …, tak se dá udělat rebase a do toho todo skriptu napsat

p sha-prvniho-commitu
p sha-druheho-commitu

jsem celkem spokojený uživatel svn, ale tohle se mi hodně líbí :)

Možná jsme tím měli začít :)

Opravdu dobrý článek. Předpokládám, že řady pochybovačů značně prořídly :)

O těchto možnostech úpravy historie jsem vůbec nevěděl a opravdu moc se mi to líbí.

Umí TortoiseGit pracovat s git rebase? Přecejen ručně přepisovat „pick“ na „e“ je trochu otravné.

> Historie se nesmí měnit
Pokud uvazujeme podminky z clanku (lokalni, nezverejnene commity), proc se nesmi menit historie?

Kde konkretne pri uklidu historie vznikne bordel? Myslite, ze by to lidi delali kdyby vysledkem byl bordel?

Ja jsem zrovna dneska delal cistku, prekopaval jsem nekolik commitu. Zacinal jsem s par na muj vkus vetsimi zmenami, vysledkem je prehledna serie, kde je v kazdem commitu jedna izolovana zmena. Kdyz budu v budoucnu treba chtit zkoumat, kde se stala chyba, tak to budu mit rozhodne snazsi.

> Spíš se nikomu nechce zakládat další flame.
Heh, hezký názor :). Rozhodně osobně jsem z flamů dost unavený, jak už se jeden objeví, mizím.

Každopádně osobně si myslím, že na tom něco je. Na obojím. Souhlasím s tím, že historie by se neměla měnit, že by měla být něco pevného, o co se dá opřít. Ale zase na druhou stranu uznávám, že jsou důvody, proč ji upravit. Hodně častým důvodem např. je to, že se náhodou podaří odeslat soubor s heslama (i když uznávám, že pak už je pozdě bycha honit vzhledem k tomu, že už si je mohl někdo stáhnout – i když to lze ověřit v logech). Mě osobně se jeden důvod naskytl poměrně nedávno; dřív jsem nepoužíval žádný verzovací systém (přeci jen jsem spíš začátečník) a spíš jsem si dělal „zálohy“ s postupně číslovanými adresáři. Nedávno jsem si usmyslel, že potřebuji nový a skončil jsem u gitu. Tak jsem do něj začal cpát jednotlivé zálohy. No a po poměrně dlouhé práci jsem zjistil, že když checkoutuji starší verzi – nefunguje. Velice brzy jsem našel příčinu – systém (jedná se o PHP stránky) potřebuje k práci složky, jejichž existenci předpokládá, ale které jsou prázdné – no a git prázdné složky neukládá a tedy nevytváří. A tak, i když ve skutečné historii byly, do historie gitu se nedostaly a bylo potřeba historii upravit a nacpat do nich něco, aby ty složky zůstaly (např. .gitignore nebo .htaccess jsou velmi dobře použitelné).

Proto se mi třeba líbí, že git při změně historie změní hashe všech dalších commitů, takže třeba změna veřejného repositáře nemůže zůstat bez povšimnutí (a u kterého se obecně značně nedoporučuje historii měnit).

Osobně to vlastně vnímám, že je to o tom, co člověk může a co člověk musí. Je to jako s programovacími jazyky – taková Java člověku přikazuje, jak má struktura kódu vypadat (jedna třída na stejnojmenný soubor, systém balíčků), ale C++ dává mnohem více volnosti, se kterou přichází zodpovědnost a nutnost určité disciplíny. Ne že bych tím chtěl Javu nebo SVN hanit (i když Javu fakt nemusím, respektive pomalost programů v ní), na druhou stranu když někdo umí dobře a rychle dělat v Javě, proč se učit něco dalšího :).

No vidíte. Kdybyste chvíli počkal, co má ten Git vlastně ve forotě, mohli jsme si ušetřit nesmyslné přestřelky.

> Článek jsem četl a nenašel jsem v tom nic, co by mi zaplatilo práci na změně (…)

No a jak už to bývá, nakonec se i docela shodneme. Jak píšu v komentáři již k prvnímu článku:

Build proces, ticket system, oprávnění, sofistikované hooky, atd atd navázané na SVN je samozřejmě problém jen tak zbůhdarma migrovat na jiný systém, jedno jaký. Tady musím být přesvědčen, že mi migrace přinese nějakou hmatatelnou výhodu.

Ale na světě je spousta jiných lidí a pro ty to může být zase jinak…

Myslím, že se mýlíte v pohledu na danou věc. Rozhodně se nesmí měnit historie, kerou už někdo jiný viděl, nebo dokonce použil. Stejně jako se tu nedají (snadno) měnit už odeslané příspěvky. Ale opravit chyby v příspěvku než ho odešlu na server bych naopak považoval za slušnost. A to je právě ta „povolená“ změna historie v gitu.
Myslím, že zdejší diskuze bude rozhodně přehlednější s tímto příspěvkem v tomto tvaru, než kdybych tu odeslal první verzi a hned za ní 21 menších, které by opravovaly překlepy a 6, které by vsouvaly do toho prvního zapomenutá slova a upravovaly věty. (čísla průběžně upravována podle toho, jak jsem tento příspěvek psal)

Pokud budu chtít k tomuto příspěvku něco dodat, tak samozřejmě použiju další (protože tento už BYL) zveřejněn – a zase si ho před odesláním přečtu, opravím a případně rozdělím na víc logických celků.

Představte si centrální server jako root.cz a lokální repozitář jako rozepsané okénko v prohlížeči – dokud neklepnete na „Odeslat“ je lepší nalezené chyby opravit a špatně seřazené odstavečky přerovnat do logického pořadí. Jakmile odklepnete „Odeslat“, tak už je historie daná a nesmí se měnit.

> Umí TortoiseGit pracovat s git rebase?

Zdá se mi, že ne, ale třeba někdo bude vědět. TortoiseGit je spíš na „takové to domácí verzování“.

> Přecejen ručně přepisovat „pick“ na „e“ je trochu otravné.

No, pokud má člověk tzv. „dobrý editor“, v _column mode_ se to dá editovat velmi elegantně a rychle.

Necekal jsem ze se v clanku dozvim neco noveho, ale delat rebase vetve dovnitr sebe samotne me fakt jeste nenapadlo. Zajimave, diky za tip.

-Yenya

V clanku s takovymhle titulkem jsem trochu cekal i zminku o git filter-branch, ktery funguje v trochu jinem modu nez git rebase -i, je o neco lowlevelovejsi a urcen na batch processing vetsich kusu historie. Napr. jim lze snadno hromadne opravovat informace o autorstvi commitu, smazat z cele historie nejake nezadouci soubory, nebo naopak „vykousnout“ z historie jen tu, ktera se tyka urciteho podadresare.

> V clanku s takovymhle titulkem jsem trochu cekal i zminku o git filter-branch (…)

Ono to tam není ze dvou důvodů:

a) Předně, o obou klasických použitích filter-branch (odstranění souboru z celého stromu, změna autorství) byla řeč hned v prvním článku.

b) přijde mi lepší pořádně vysvětlit jak funguje rebase -i, protože filter-branch je vskutku dost low level a běžně by si s ním lidi moc hrát nemuseli. Na úpravy historie většinou bohatě stačí rebase -i a není potřeba vytahovat ještě ostřejší nožík :)