Jak v gitu rozdělit už mergnuté změny (diskuse)

[elenril]

To ti tam ale zbyl merge commit, ne? Já bych tady použil reflog.

[mess]

Myslím, že ten byl mezi těmi commity, co se "odrolovaly" zpět, není-liž pravda.

[Let_Me_Be]

V samotnem gitu urcite (na uklid ale mame git gc) na te vetvi, kterou prave vyresetoval ne.

[cronin]

Nie ak merge bol fast-forward.

[zoul]

Aha, to je pravda. Nemohl jsem ho najít, tímhle se to vysvětluje.

[Josef Kufner]

Když se podíváš na ten merge commit, tak tam uvidíš dva rodiče. Jedním z nich je ta původní větev, kterou jsi mergoval do hlavní.

Další možnost (kterou nemám otestovanou) je použít rebase -i, kterým vyhodíš ten merge commit. To by teoreticky mohlo zachovat změny provedené po mergi.

[pht]

Kdyby to bylo SVN, tak bych to udělal tak, že reverse mergnu ty commity, čímž je vlastně oddělám (undo commit) a pak si tam cherry picknu to, co chci. Alternativně můžu undo jen ty změny co nechci.

Git do takových detailů neznám. Je to u gitu natolik jiné že se musí používat hrůzně znějící reset --hard?

[elenril]

No nevim co je na reset --hard hrůzného, pouze vyresetuje stav indexu (a s --hard i souborů) k požadovanému commitu. Mně spíš přijde hrůzný ten SVN popis

A ano, co se týče vnitřností je git dost odlišný (a IMO neporovnatelně lepší, jak vůbec může někdo dobrovolně používat SVN </flame>).

[pht]

IMO neporovnatelně lepší

Zkuste to rozvést?

[elenril]

Nechce se mi znova převypravovat, co už přede mnou lépe řekli jiní, doporučil bych prezentaci samotného Linuse o gitu (je sice hodinu dlouhá, ale stojí za to) a Why Git is Better than X.

Obzvláště pokud člověk nemá commit access, mi přijde SVN prakticky nepoužitelné na cokoliv, co by zabralo víc jak jeden commit.

[pht]

Why is git better znám a na to video se ještě kouknu v naději že pochopím proč "jsou vnitřnosti nesrovnatelně lepší".

Ale zatím jsem se nic nedověděl. Téměř všechny* "why" jsou o tom, že git je distribuovaný. Ale to mě v tuto chvíli nezajímá. Mě zajímá ta konkrétní mechanika toho revertování změn. A u toho je přece jedno, jestli mám repo tam nebo tady.

Proč je reverzní mergování (aka undo commit) tak hrůzné? Dejme tomu, že chci z revizí 1-10 uncommitnout rozdíl revizí 5-6 (aka změnu v commitu 6). Tak SVN řeknu: aplikuj změnu 5-6 ale obráceně. To dává smysl. Jak to řeknu gitu? Když ho resetnu (nebo dokonce hard) na verzi 5 tak to nebude to samé, protože tím oddělám všechny změny 5-10. Nebo ne?

* až na staging area. OK, pěkné, ale nesouvisí s otázkou.

[elenril]

Aha, tak to jsme si nerozuměli, myslel jsem, že otázka je na git všeobecně, ne jen na merge.

Co se toho týče, neříkal jsem že _je_ hrůzné, ale že popsaný postup _vypadá_ víc hrůzně, než v gitu. V blogu byly dva příkazy, první z nich vytvořil novou větev založenou na současné a druhý resetoval současnou větev (tj. master) o 4 commity dozadu.

Jak jsem psal v prvním komentáři, já bych použil reflog, kde se uchovávají hashe minulých stavů stromu a pak se dá jednoduchým git reset --hard hash resetovat do libovolného minulého stavu, i kdyby nebyl dosažitelný z žádné současné větve.

Kdybych chtěl editovat historii komplikovanějším způsobem, tak bych použil rebase v interaktivním módu asi takto:

[ wiskas@zohar ~/src/ffmpeg (new_conv2)]$ git rebase -i master

to otevře vim se seznamem commitů oproti větvi master.

pick 1e0c8de metadata: wrap conversion tables in a struct.
pick 7f728c3 metadata: add callbacks to conversion system.
pick 2fa0890 matroska: convert tag keys to uppercase when muxing.
pick 0b0fbeb id3v2: merge TYER/TDAT/TIME frames to "date" tag on conversion.
pick 3b60299 asf: truncate date to year when muxing.

# Rebase aa5b13a..3b60299 onto aa5b13a
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Jednotlivé commity tady můžu označit pro smazání, editaci atd a git to zařídí.

[zoul]

Why is git better znám a na to video se ještě kouknu v naději že pochopím proč "jsou vnitřnosti nesrovnatelně lepší".

V tomhle zrovna pomůže spíš ten Pro Git než Linusova přednáška. Pamatuju si, že se mi líbila, ale že jsem se moc nedozvěděl. Tedy kromě toho, že je git nesrovnatelně lepší Víc se mi líbilo video od Scotta Chacona.

[petr_p]

git revert? Git funguje prostě jinak. Jde o to, co přesně chcete udělat a koho tím chcete ohrozit. Existuje více způsobů, jak dosáhnout téhož.

[zoul]

Proč je reverzní mergování (aka undo commit) tak hrůzné?

Pokud tomu dobře rozumím, budeš mít v historii nový commit se spoustou smazaných změn?

Jak to řeknu gitu? Když ho resetnu (nebo dokonce hard) na verzi 5 tak to nebude to samé, protože tím oddělám všechny změny 5-10. Nebo ne?

To, co jsem udělal já, vrátí ukazatel větve master na commit 5. Commity 6–10 zůstávají v repository a na poslední z nich ukazuje větev new-feature, kterou jsem založil před posunem master. (Teda takhle si to alespoň já představuju

[zoul]

Á, pardon, odpovídal jsem na něco úplně jiného. Nediskutovat po jedenácté, nediskutovat po jedenácté, nedisk…

[zoul]

Poslední dobou hodně střídám git a Subversion a pár věcí mi na Subversion opravdu vadí. Jednou z nich je rychlost – když chci nakouknout do historie, počkám si klidně i pět vteřin. Když jsem zrovna v otáčkách, během těch pěti vteřin mi „spadne řetěz“, je to pro mě nepříjemné zpomalení.

Dál se mi na gitu hrozně líbí staging. Málokdo má tu disciplínu, aby v rámci jednoho commitu skutečně nezměnil víc věcí najednou. U gitu to není problém, provedené změny si prohlédnu a vyzobu do několika samostatných commitů. Bez problémů takhle můžu oddělit i změny provedené ve stejném souboru.

Pak jsou to často drobnosti. Barevný diff, pager ve výstupu a podobně. Jasně že to jde zařídit i v Subversion, ale git je zkrátka pohodlí.

O věcech jako offline provoz vůbec nemluvě. Když má zrovna server špatnou chvíli, s gitem mi to může být úplně fuk. Totéž když mě teď čeká stěhování nebo když si potřebuju vzít práci někam s sebou.

Branching je v gitu zlatý. Linus to řekl velice trefně – ten rozdíl v rychlosti není jen kvantitativní, to je opravdu úplně jiná práce. V Subversion bych si každou větev dvakrát rozmýšlel. (Na druhou stranu je mi nepříjemné, jak se lidi do Subversion furt strefujou. Že je git lepší neznamená, že je Subversion špatné.)

[pht]

Chápu. Git používám na svoje lokální projekty, ale to je dost málo. Dříve jsem měl svn repo o adresář vedle ale pak jsem si uvědomil že je zbytečné mít 2 adresáře.

Při práci se SVN po síti jsem nikdy 5 vteřin nečekal. Na gigabitové síti se slušným HW opravdu není síť limitující faktor, nýbrž disk, a na ten si počkáte i u gitu.

Staging nechci, ale to je pouze můj názor. Není to o disciplíně, ale o tom, že co máte v historii je v podstatně větším bezpečí, než to, co se váli v working copy. To už je lepší používat ty mikro branche nebo funkci "šuplík" (vytvoření patche a schování do šuplíku).

Ale mikro branchování lze dělat i na SVN. "svn copy" (vytvoření branche) a následné "svn switch" (přepnutí working copy) jsou téměř no-op příkazy.

Nicméně mě by zajímaly takové ty věci pokročilejší. Například to reverzní mergování (undo commit)? Nebo jak řeší git přesun souborů/adresářů a následný merge nové struktury? Je tam něco jako tree conflict? Uchovává snapshoty nebo delty? Co se stane, když z repozitáře smažu 3 náhodné revize? Jak řešíte workflow když chcete mít master copy z které se třeba dělá oficiální build? Jak řešíte workflow ve skupině? Je nutné aby každý vývojář měl u sebe git démona nebo sshd kvůli pullování? Jak řešíte zálohy?

[zoul]

Při práci se SVN po síti jsem nikdy 5 vteřin nečekal. Na gigabitové síti se slušným HW opravdu není síť limitující faktor, nýbrž disk, a na ten si počkáte i u gitu.

My nemáme kancl, pracuju doma. To je pak síť výrazný bottleneck.

Není to o disciplíně, ale o tom, že co máte v historii je v podstatně větším bezpečí, než to, co se váli v working copy.

Nevím, jestli si rozumíme. Nejde o to, že bych si něco syslil doma a pak to teprve pustil na síť. I kdybych po každém commitu tlačil změny do centrálního repository, díky stagingu mám lepší kontrolu nad rozdělením provedených změn do commitů.

Ale mikro branchování lze dělat i na SVN. "svn copy" (vytvoření branche) a následné "svn switch" (přepnutí working copy) jsou téměř no-op příkazy.

Možná na té rychlé síti, v tomhle nás jasně ovlivňuje pracovní prostřední. Na většinu zbývajících otázek neznám kloudnou odpověď, bohužel, v gitu se zatím moc nevyznám. Něco málo:

Git uchovává snímky, nikoliv delty. V týmu zatím git nepoužíváme kvůli absenci opravdu příjemných grafických frontendů (kluci mají averzi k příkazové řádce a grafické nadstavby gitu zatím nejsou tak pěkné jako GUI nad Subversion). Pullování se běžně řeší veřejným repository. Na soukromém pracuju a když jsem hotov, pushnu do veřejného repository na serveru, odkud si může zbytek týmu změny stáhnout (= není potřeba dělat z vlastní mašiny server).

[pht]

díky stagingu mám lepší kontrolu nad rozdělením provedených změn do commitů.

To chápu, ale uvažuju, co se stane s nestagovanými změnami. Budou dále ve working copy a riziko že se náhodou přepíšou (nebo ztratí při změně branche) se zvyšuje s jejich věkem. IOW nejlepší je dělat check in všeho tak cca každou půl až hodinu.

Možná na té rychlé síti, v tomhle nás jasně ovlivňuje pracovní prostřední.

Zrovna tohle by mohlo trvat obstojně dlouho i na pomalé síti. Bude se doslova jednat o přenos pár bajtů. Ale je fakt, že SVN exceluje hlavně v uzavřených týmech na lokálních sítích.

kluci mají averzi k příkazové řádce a grafické nadstavby gitu zatím nejsou tak pěkné jako GUI nad Subversion

Tohle se dá řešit nějakým IDE ;)

Na soukromém pracuju a když jsem hotov, pushnu do veřejného repository na serveru

Já jsem právě někde četl že je lepší dělat vždy jenom pull? Pokud děláte tohle, tak to je vlastně stejná situace jako byste měli centrálně SVN a používali git+svn? A pokud udělám push, pak pushuju do nějaké aktivní větve, nebo můžu tímto způsobem pushnout třeba 3 branche?

[zoul]

To chápu, ale uvažuju, co se stane s nestagovanými změnami.

Žádné nejsou. Jde o, že se třeba vypravím do souboru X opravit chybu. Cestou si v polovině souboru všimnu jiné, tak ji zároveň opravím též. Pak můžu pomocí git add -p obě změny rozdělit do dvou nezávislých commitů, které jdou okamžitě do historie.

Zrovna tohle by mohlo trvat obstojně dlouho i na pomalé síti. Bude se doslova jednat o přenos pár bajtů.

Nevím proč, ale trvá to. Máme mizerný server v zámoří, zatím nebyl čas přejít na lepší řešení. V gitu je to místní operace:

$ time ( git branch foo && git branch -D foo )
Deleted branch foo (was 5490107).

real	0m0.122s
user	0m0.004s
sys	0m0.016s

Já jsem právě někde četl že je lepší dělat vždy jenom pull? Pokud děláte tohle, tak to je vlastně stejná situace jako byste měli centrálně SVN a používali git+svn? A pokud udělám push, pak pushuju do nějaké aktivní větve, nebo můžu tímto způsobem pushnout třeba 3 branche?

Veřejné repository pro pushe jsou naprosto běžná praxe, viz celý GitHub. Rozdíl je v tom, že push můžu dělat třeba jen jednou denně, když se práce stabilizuje, když mám připojení k síti, když končím s prací. Když mi během dne ujede ruka a vyrobím nesmyslný commit, můžu ho zredigovat podle potřeby a veřejná historie zůstane čistá. Pushnout se dá cokoliv. Jeden commit, jedna větev, víc větví, tagy.

[pht]

Jde o, že se třeba vypravím do souboru X opravit chybu. Cestou si v polovině souboru všimnu jiné, tak ji zároveň opravím též.

Aha, tak to já si radši napíšu na papírek, protože se může stát, že bych mezitím zapomněl na tu první chybu. :)

real	0m0.122s

Tady asi budou hrát roli síťové latence, případně mrštnost serveru.

$ time (svn cp ^/trunk ^/branches/boo -m testboo && svn rm ^/branches/boo -m testboo)

Committed revision 3942.

Committed revision 3943.

real    0m0.856s
user    0m0.013s
sys     0m0.013s

Veřejné repository pro pushe jsou naprosto běžná praxe

OK. Já sleduju jen vývoj jádra a pár dalších projektů a tam lítají spíš pull requesty.

[zoul]

Timing respekt :) Pull requesty s pushováním úzce souvisí – vesměs se tahá z veřejného repository vývojáře (do kterého on tlačí změny ze svého soukromého repo). Viz třeba tuhle obrázek z Pro Git.

[Jirka P]

Například to reverzní mergování (undo commit)?

Je možné přepsat historii tak, aby ten commit vypadl (viz výše), nebo je možné přidat commit revertující ty změny, stejně jako v SVN (git revert). Každé má své výhody i nevýhody.

Nebo jak řeší git přesun souborů/adresářů a následný merge nové struktury?

Z vlastní zkušenosti (ale stalo se mi to jen jednou) to řeší dobře. Někdy je ale ta detekce kopií dost otravná.

Co se stane, když z repozitáře smažu 3 náhodné revize?

Jak smažu? Pokud půjdu na killing spree do adresáře .git a smažu náhodné soubory, pak to pochopitelně přestane fungovat. Jinak nevím, co myslíš tím "smažu".

Jak řešíte zálohy?

Nevím jak to kdo řeší, ale kromě periodického fetchování do zálohy funguje na .git adresář i cp -a, takže i jakýkoli jiný zálohovací program.

[pht]

Někdy je ale ta detekce kopií dost otravná.

Např?

Pokud půjdu na killing spree do adresáře .git a smažu náhodné soubory, pak to pochopitelně přestane fungovat. Jinak nevím, co myslíš tím "smažu".

Jo, myslím to takhle, respektive třeba když se to nějakým způsobem poškodí. Jde nějak přesněji definovat co a za jakých podmínek přestane fungovat?

funguje na .git adresář i cp -a, takže i jakýkoli jiný zálohovací program.

Jasně, myslel jsem to spíše procesně. U SVN stačí zálohovat repo, u gitu to vypadá že by si měl zálohu každý pořešit sám?

[Josef Kufner]

V gitu zálohy řešit nemusíš nijak víc než jak zálohuješ celý počítač.

Navíc tím, že je to distribuované, tak má každý kopii, takže pokud přijdeš o svůj repositář, tak ztratíš maximálně pár nezveřejněných commitů. Pokud přijdeš o server, tak jen řekneš ostatním, ať to uploadnou zpět.

[Jirka P]

Někdy je ale ta detekce kopií dost otravná.

Např?

Např. když je v projektu hodně skoro stejných souborů (třeba makefily kde většinu zabírá licence), tak to detekuje kopie in mezi naprosto nesouvisejícími soubory a je spíš loterie, který si vybere. Pak to minimálně vypadá blbě v git show.

Jo, myslím to takhle, respektive třeba když se to nějakým způsobem poškodí. Jde nějak přesněji definovat co a za jakých podmínek přestane fungovat?

Pokud si smažeš blob (data nějakého souboru), tak jsi o něj přišel. Pokud commit, tak teoreticky jde (pokud ho nutně nepotřebuješ) předělat historii větve tak, aby na ní nebyl. Když si smažeš odkaz na větev nebo tag, jde to spravit poměrně bezbolestně (pokud víš kam ukazoval - není potřeba pamatovat si sha1, stačí prohrabat repozitář a vybrat si z nereferencovaných commitů ten svůj. Pokud smažeš pack, záleží, co v něm bylo.

[zoul]

Doporučuju knihu Pro Git, recenzovala se aj tu na Ábíčku. Sám jsem ji proběhl a schovávám si ji na léto, zatím se v gitu orientuju jen povrchně. Vevnitř vypadá moc hezky, šaškování s větvemi často spočívá jen v přehazování ukazatelů (nejspíš i to zle znějící reset --hard).