Proč bych měl přejít ze SVN na GIT? (vážně)

[Ondřej Novák]

Na to používám Control+Z (Undo)

A co kdyz chces vratit neco, cos na tom souboru udelal nekdy driv?

//MODS: navrhuju lock, zacina mi to pripominat diskuzi s trollem
[/quote]

Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)

[Reklama]

[Sten]

Jmenuje se pull.

Možná by ale bylo vhodnější zadat do Googlu „základy Gitu“.

To jsem právě udělal a napsalo to "příkaz skončil nenulovým statusem" - jo zatím používam gclient sync ale trvá to strašně dlouho

Tohle rozhodně neudělal Git, ale nějaká „chytrá“ nadstavba, kterou používáš.

Obdivuju, že si to můžeš dovolit. Já vyvíjím nové vlastnosti a zároveň podporuju vydaný software pro několik desítek klientů. A nemůžu říct klientovi, že tu padačku opravím, až za dva měsíce naimplementuju to, co mám právě rozdělané, nebo že dostane další beta verzi, která sice opraví nahlášené chyby, ale možná bude mít úplně nové chyby, protože je v ní spousta nového kódu.

Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?

Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.

Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)

V Gitu použiji jeden příkaz a vidím, co vracím. Navíc pokud jsem to ještě nepushnul, můžu ten vadný kód úplně odstranit z historie. Ale to je asi příliš složité...

[Ondřej Novák]

Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?

Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.

Že bys taky neuměl pracovat v SVN? Kde jsi vzal 50 workspaců. Víš že existuje svn switch?

Na druhou stranu, mě právě vyhovuje mít víc workspaců, pokud potřebuju pracovat na víc větví. Mohu třeba pracovat naráz na obou, třeba během překladu jedné větve vyrábím hotfix v druhé větvi. Možná že to v tom gitu nějak jde taky, ale zatím se mi podařilo jen pro každou větev mít jednu aktivní a další větve ... někde skryté... ale třeba se tu dozvím, jak se to dělá.

Když už o tom mluvíme, napadá tě, jak bych mohl verzovat větev, aniž bych si musel držet celý repozitář? Já zatím do SVN ukládám patche.

Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)

V Gitu použiji jeden příkaz a vidím, co vracím. Navíc pokud jsem to ještě nepushnul, můžu ten vadný kód úplně odstranit z historie. Ale to je asi příliš složité...

Nemožnost opravovat historii jsem bral (a doposud beru) jako obrovský plus SVN (s výjimkou toho, když se někomu opravdu inteligentnímu podaří do SVN commitnout heslo k databázi). I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence

[Lol Phirae]

Ano, CTRL+Z a visual compare je opravdu super náhrada za git...

[perceptron]

Ctrl-Z chapem pri jednom subore, ale co ked ta zmena je refaktoring cez pat suborov?

I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence

mne sa zda, ze editovat komity je mozne len ak neboli pushnute

[Reklama]

[Ondřej Novák]

Ano, CTRL+Z a visual compare je opravdu super náhrada za git...

Ano, já bych fakt chtěl tohle vidět v praxi.

1) Semhle dopíšu for (auto &x: observers) x.update(..)
2) zmáčknu Ctrl+S
3) přepnu do terminálu a napíšu git commit -a;
4) přepnu zpět
5) ah, ještě bych tam mohl napsat observers.clear()
6) zmáčknu Ctrl+S
7) přepnu do terminálu a napíšu git commit -a;
..
..
..
Jaký máte výkon source-lines/hour?

[Ondřej Novák]

Ano, já bych fakt chtěl tohle vidět v praxi.

..
..
..

Sakra, já zapoměl, no jasně, ještě napsat popis commit "připsal jsem notifikaci observů"
no a ještě bych to měl mít v komentáři, takže opět 1,2, git commit -a "dopsal jsem to do komentaru"

[dustin]

Pushnutí vadného commitu je chyba, ne výhoda. Zaneřádím historii projektu a hlavně tím otravuji život i ostatním vývojářům, kteří si vadnou verzi stahnou a budou se s tím muset potýkat. Před pushem je potřeba se rozmyslet, zda je to opravdu správně - třeba zrovna to heslo v commitu vyrobeném před několika hodinami, po kterém následuje deset dalších. Pak už se historie opravit nedá (nebo jen pracně). V git rebase commit vyhodím/opravím.

Pěkná práce s commity je při přispívání do kernelu. Správci dostanou celý commit (např. přes git-send-mail), zrevidují jej, skriptem (zřejmě automaticky spouštěným) zkontrolují štábní kulturu a když je to v pořádku, přidají jej rovnou z mailového klienta do svého repozitáře, např. do některé své větve na git.kernel.org. Pak ve vhodný čas Linusovi jen pošlou commity, které chtějí mergnout do nové verze kernelu. Commity si rozdělují na kritické, které chtějí do ostré verze dostat co nejdříve, a normální, které počkají na další otevřené okno pro mergování do nové verze. Proto musí být co nejmenší a musí řešit jen jeden problém, aby se s nimi dalo pracovat jako s ucelenými bloky dobře popsaných změn, které jsou natolik jednoduché, že je lze snadno projít a zkontrolovat.

[Sten]

Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?

Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.

Že bys taky neuměl pracovat v SVN? Kde jsi vzal 50 workspaců. Víš že existuje svn switch?

Ano, vím, ale switch je spíš hack než reálně použitelná náhrada git checkout, vyžaduje to plné URL a rychlost (nebo spíš pomalost) je otřesná. Proč myslíš, že se v SVN běžně používá pro každou branch vlastní adresář?

Na druhou stranu, mě právě vyhovuje mít víc workspaců, pokud potřebuju pracovat na víc větví. Mohu třeba pracovat naráz na obou, třeba během překladu jedné větve vyrábím hotfix v druhé větvi. Možná že to v tom gitu nějak jde taky, ale zatím se mi podařilo jen pro každou větev mít jednu aktivní a další větve ... někde skryté... ale třeba se tu dozvím, jak se to dělá.

V Gitu to jde úplně bez problému, dokonce několika způsoby, podle toho, jak to potřebuješ:

• pokud chceš nové commity ukládat do toho nového repozitáře, ale historii brát z jiného, tak pomocí git clone --reference cesta URL
• pokud chceš oddělený repozitář a několik adresářů, kde budeš vyvíjet, tak pomocí git clone --separate-git-dir cesta_k_repozitáři URL a následujícím krokem
• pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard

Když už o tom mluvíme, napadá tě, jak bych mohl verzovat větev, aniž bych si musel držet celý repozitář? Já zatím do SVN ukládám patche.

git clone --single-branch --branch větev URL

Ctrl-Z chapem pri jednom subore, ale co ked ta zmena je refaktoring cez pat suborov?

I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence

mne sa zda, ze editovat komity je mozne len ak neboli pushnute

Jde editovat i commity, které již byly pushnuté, ale historii na serveru to nezmění a bude potřeba merge (tedy jde to vynutit, ale to je bad practice). Tohle se týká spíš stupidních chyb jako překlep v dokumentaci.

Ano, CTRL+Z a visual compare je opravdu super náhrada za git...

Ano, já bych fakt chtěl tohle vidět v praxi.

1) Semhle dopíšu for (auto &x: observers) x.update(..)
2) zmáčknu Ctrl+S
3) přepnu do terminálu a napíšu git commit -a;
4) přepnu zpět
5) ah, ještě bych tam mohl napsat observers.clear()
6) zmáčknu Ctrl+S
7) přepnu do terminálu a napíšu git commit -a;
..
..
..
Jaký máte výkon source-lines/hour?

git commit -a --amend

[Ondřej Novák]

Pushnutí vadného commitu je chyba, ne výhoda. Zaneřádím historii projektu a hlavně tím otravuji život i ostatním vývojářům, kteří si vadnou verzi stahnou a budou se s tím muset potýkat. Před pushem je potřeba se rozmyslet, zda je to opravdu správně - třeba zrovna to heslo v commitu vyrobeném před několika hodinami, po kterém následuje deset dalších. Pak už se historie opravit nedá (nebo jen pracně). V git rebase commit vyhodím/opravím.

Pěkná práce s commity je při přispívání do kernelu. Správci dostanou celý commit (např. přes git-send-mail), zrevidují jej, skriptem (zřejmě automaticky spouštěným) zkontrolují štábní kulturu a když je to v pořádku, přidají jej rovnou z mailového klienta do svého repozitáře, např. do některé své větve na git.kernel.org. Pak ve vhodný čas Linusovi jen pošlou commity, které chtějí mergnout do nové verze kernelu. Commity si rozdělují na kritické, které chtějí do ostré verze dostat co nejdříve, a normální, které počkají na další otevřené okno pro mergování do nové verze. Proto musí být co nejmenší a musí řešit jen jeden problém, aby se s nimi dalo pracovat jako s ucelenými bloky dobře popsaných změn, které jsou natolik jednoduché, že je lze snadno projít a zkontrolovat.

A oni se dívají i na historii? nebo je zajímá finální stav. Protože pokud vím, úplně stačí posílat patch.  Na vadnou revizi samozřejmě často přijde někdo jiný. Když pracuji ve větvích, není možné někomu zaneřádit projekt. Nebo to něčemu odporuje? Evidence vadné revize ve větvi je užitečná, ale pokud byla ta revize rollbacknuta, pak by snad neměla nikomu škodit

Naopak si nedokážu představit, že před odchodem ze zaměstnání na poslední chvíli čistím commity (to už bych tedy raději dělal ráno, ale to zas spousti věci prostě nemá člověk v hlavě)

[dustin]

Commituji, až je úprava hotová. Opravy commituji hned. A pak se mohu vrátit k vývoji feature, protože když bude potřeba (např. zapomenutý necommitnutý soubor při refaktoringu, bez kterého commit nepůjde nezkompilovat), následující commit přes interaktivní rebase snadno spojím s některým z předchozích. Samozřejmě commituji přes IDE (IntelliJ), kde řeším i rozdíly mezi commity. Jen je škoda, že zatím IntelliJ neumí snadno commity jen chunků a rozpad commitu na dva, to by se hodně  moc hodilo.

[Sten]

pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard

Oprava, symlink na celý .git nefunguje. Je potřeba udělat symlink na .git/objects a zbytek zkopírovat.

[dustin]

A oni se dívají i na historii? nebo je zajímá finální stav. Protože pokud vím, úplně stačí posílat patch.

Samozřejmě každý commit řeší konkrétní problém, je vzniklý právě spojením (squash v interaktivním rebase) všech tvých malých commitů, které se toho týkaly, které sis vyrobil třeba během týdne. Mrkni např. na http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/079445.html a následné zprávy - 13 po sobě jdoucích commitů. Ty určitě nevznikly najednou, ale spojením spousty menších, aby v tom nebyl bordel. A pak se diskutuje už o konkrétních commitech, některé opraví a pošle je znovu.

Samozřejmě ve firemním vývoji to takto pečlivě neděláme, spojují se jen commity, kde je to jasné, ale je potřeba na to myslet a mít nástroj, který tohle umožňuje.

Jinak to "čištění" commitů před pushem ve firmě obnáší jen jejich případné spojení či přeřazení, práce na pár sekund. S commity do kernelu je to jiné, tam se musí daleko pečlivěji. Ale pak ten commit zůstane v kernelu nafurt, veřejně všem na očích.

[Ondřej Novák]

Ano, vím, ale switch je spíš hack než reálně použitelná náhrada git checkout, vyžaduje to plné URL a rychlost (nebo spíš pomalost) je otřesná. Proč myslíš, že se v SVN běžně používá pro každou branch vlastní adresář?

Sám víš, že v SVN to není plnohodnotný "adresář", protože se používá sdílení. To co si člověk vytáhne jako větev je z větší části sdílené, ale pro účely snadné práce se to tváří jako adresář.

O pomalosti switch nic nevím. Bylo to pod mojí rozlišovací schopností. Jo zobrazí se asi na pár sekund progress bar. svn switch nedělá nic jiného, než rozdílový update (aplikuje patch), takže to o zas tak pomalé není. Jo, když tam má člověk lokální změny, tak to je pomalejší, protože se to zároveň merguje. Ale to už je bad practice

V Gitu to jde úplně bez problému, dokonce několika způsoby, podle toho, jak to potřebuješ:

• pokud chceš nové commity ukládat do toho nového repozitáře, ale historii brát z jiného, tak pomocí git clone --reference cesta URL
• pokud chceš oddělený repozitář a několik adresářů, kde budeš vyvíjet, tak pomocí git clone --separate-git-dir cesta_k_repozitáři URL a následujícím krokem
• pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard

Bod 3 ve windows bych vyřadil. další dvě mohu vyzkoušet. Bod 1 mi přijde jako nějaký kanón na vrabce. K čemu další repozitář?

git clone --single-branch --branch větev URL

Vyzkouším zítra. Nicméně podle toho jak funguje clone se bojím, že stejně skončim s celým webkitem a chromiem v separátním adresáři. Nebo ne?

git commit -a --amend

nepochopil jsem odpověď, záměrem bylo zjistit, jaké všechny činnosti navíc musejí dělat programátoři v git a jak často.

[dustin]

Některé commity do kernelu samozřejmě vznikají i retrospektivně, ručním rozdělením funkčního kódu souboru do jednotlivých commitů (právě commity chunků, to myslím SVN neumí). To je pak docela pracné. Jednodušší je mít více malých commitů a ty squashnout.