Názory k článku
Mercurial 6.0 je poslední verzí s podporou Pythonu 2

Připadá mi škoda, že zvítězil Git. Mercurial se mi v několika ohledech líbil víc, hlavně automatická správa multi-head a podpora pro rozšíření. No co, žiju i s Gitem...

Presne, museli sme prejst na git, ale Hg som mal radsej

Jsem Mercurial opustil, protože nutně potřebuji rebase :)

Patřím k těm, kteří považují rebase za zlo a kacířství :)
Nicméně pro Mercurial existuje rozšíření Rebase:

https://www.mercurial-scm.org/wiki/RebaseExtension

Jak praví klasik, každý fundamentalismus je na ... Zlo a kacířství je to ve sdílených repozitářích (a i tam jen u větví, kde se očekává, že je sdílíte s ostatními). Při vývoji něčeho netriviálního, ve fázi před tím, než se to dostane do sdílených větví, je rebase naopak velice užitečný nástroj.

Vycházím z toho, že prakticky všechno, co vyvíjím, se někdy bude sdílet. Někdo to řeší tak, že při otevření přístupu z vnějšku se prostě provede jeden gigantický commit a veškerá historie se tím ztratí, ale to mi připadá jako blbost (proč v takovém případě vůbec používat SCM?). Zvlášť slavná kauza SCO ukázala, jak je důležité mít prokazatelné trasování kódu.

Ale rebase neznamená, že by se dělal jeden velký commit nebo že by zmizelo trasování kódu.
Užitečný může být třeba rebase před zveřejněním, takže je historie lineární a není nutný merge.

Ano, je potřeba striktně rozlišovat, jestli si hraji na svém vlastním písečku nebo zda jsem už výsledky publikoval pro ostatní - pak by historie měla být svatá a neměla by se přepisovat.

Mercurial má dobré prostředky jak to rozlišit: fáze (public vs. draft) a dobré prostředky jak tu historii přepisovat, pokud je to přípustné: rebase, histedit.

Mercurial má trochu jinou filosofii resp. výchozí přístup oproti gitu - chová se k historii šetrněji a je těžší si v něm něco rozbít nebo nenávratně smazat. Nicméně pokud člověk chce a má potřebu si např. dělat historii a grafy "hezčí", tak prostředky k tomu má.

Přinejhorším můžu "na prasáka" změnit tu fázi a přepsat i to, co už jsem publikoval, ale pak si ponesu následky...

Já potřebuju rebasovat do sdílených větví :-) (A běžně rebasujeme ve větvích, na kterých nás pracuje vícero. A je to velice praktické, a nerad bych se toho vzdával. Ale toto už by se dalo řešit, nebrání to cíli.)

Jestli "rebasem do sdílených větví" myslíte to, že před mergem do sdílené větve (nebo současně s ním) uděláte rebase, tak v tom samozřejmě žádný problém není. Naopak, často může být ku prospěchu věci, že se vyhnete příliš komplikovanému a neprůhlednému merge commitu, když je tam nějaký složitější konflikt. (Ale ani na tom nepanuje úplná shoda, třeba Linus to nemá rád, protože se pak dělá merge něčeho, co v této podobě nikdo pořádně netestoval.)

Co je problém a kvůli čemu se občas zjednodušeně tvrdí, že "rebase je zlo", je když se najednou změní commity, které už mají ostatní vycheckoutované a na kterých už možná mají postavené vlastní lokální větve s rozdělanou prací. V lepším případě jim to jen přidělá práci, v horším riskujete, že následný merge takové větve tam zavleče zpátky tu původní historii nebo - hůř - její náhodnou část. (Samozřejmě není problém jen rebase, úplně stejně by škodil "commit --amend", "rebase -i", reset někam zpátky apod., což jsou všechno velmi užitečné a často nepostradatelné nástroje pro lokální fázi vývoje.)

Je ale samozřejmě rozdíl, jestli je to malý projekt, na kterém pracují tři nebo čtyři vývojáři, kteří jsou ve stálém kontaktu, takže je lze snadno upozornit, co jste udělal a proč, nebo jestli je to veřejný projekt, kde tu branch mohou mít vycheckoutovanou desítky, stovky nebo tisíce lidí, které ani neznáte a nemáte je jak kontaktovat.

Z hlediska toho, co nástroj umožňuje, to ale roli nehraje, protože git ze své podstaty nerozlišuje, co je veřejné a co ne, takže nemá tušení, jestli ten force push je do veřejného repozitáře nebo mezi mým notebookem a pracovní stanicí.

Tak tomu nerozumím, pokud dělám na své `feature` větvi, tak dělám pull --rebase z hlavní větvě. Svoje změny dávám navrch tomu, co přichází z `main`. Pak otevřu pull-request a OK. Na bočních větvích je rebase zcela normální. Kde je problém?

https://stackoverflow.com/a/28472221

BTW Do postranní vetvě lze aplikovat i push force, pokud se opravdu potřebuji dostat stav synchronizovaný s main větvi (párkrát jsem si rozhasil kód na feature větvi). Takový fundamentalismus, co se smí a nesmí je dosti relativní.

29. 11. 2021, 09:56 editováno autorem komentáře

Aha problém není nikde. To je tak když někdo napíše, obecně, že rebase je zlo. Kde a kdy je důležité. Jasně měnit historii projektu je blbé, ale rebase se normálně používá tam, kde se používat má.

29. 11. 2021, 17:00 editováno autorem komentáře

V mercurialu po pushnutí s --force vzniknou dvě větve, nikoliv jedna jak bys (možná) očekával.

Dík, já mluvil jen o workflow v gitu v reakci na to, že rebase je špatný.. S Mercurialem jsem neměl moc zkušeností -- spíše z kulturních důvodů než že bych na něm shledal něco špatného. Ale dík za poznámku.

Toto rozšíření znám a používám (používal jsem). Bohužel to nefunguje jak potřebuju. Jakmile branch pushnu, už ji nejde změnit (aniž bych se přihlásil na server a dělal opičárny na něm). To mi velmi nevyhovuje.

Používá to vůbec dnes ještě někdo resp. něco? Java už přešla na git taky, Netbeans taky dávno a jinde jsem to v poslední době neviděl.

Jo, my to na svych projektech pouzivame (vlastni instalace).

IIRC Firefox (a Mozilla obecně). Do nedávna taky x265, ale ti už přešli na git.

29. 11. 2021, 09:40 editováno autorem komentáře

Rychlý grep skrz hlavní Gentoo repozitář potvrzuje že toho opravdu není moc. Když vyházím balíčky vyloženě určené pro mercurial (různé GUI, pluginy, atd) tak zbyde všeho všudy 25 projektů, z toho jen pár významných (sudo, hugin, x265).

app-admin/sudo
app-editors/xemacs
app-portage/layman
dev-games/physfs
dev-haskell/filestore
dev-ml/dune-configurator
dev-ml/dune-private-libs
dev-python/setuptools-scm
dev-python/vcstools
dev-qt/qt-creator
dev-util/cwdiff
dev-util/rbtools
dev-util/rosinstall
dev-util/wstool
media-gfx/graphicsmagick
media-gfx/hugin
media-libs/x265
media-libs/xine-lib
net-im/mcabber
net-im/prosody-modules
sys-apps/etckeeper
www-apps/blohg
www-apps/gitit
www-client/dillo
x11-wm/subtle

x265 už používá git.

nginx