V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Společnost Framework Computer představila novou vylepšenou verzi svého modulárního notebooku Framework Laptop 13 s Intel Core Ultra Series 1, displej s lepším rozlišením a novou webovou kameru. Přímo do Česka jej zatím koupit nelze.
Byla vydána nová verze 2.16 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
TerminalTextEffects (TTE) je engine pro vizuální efekty v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Od čtvrtka 30. 5. do soboty 1. 6. lze v Praze navštívit Veletrh vědy, tj. největší populárně naučnou akci v České republice, kterou každoročně od roku 2015 pořádá Akademie věd ČR. Vstup zdarma.
Canonical představil Ubuntu optimalizované pro jednodeskový počítač s RISC-V procesorem Milk-V Mars.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Git, distribuovaný systém správy verzí vytvořený Linusem Torvaldsem, původně pro vývoj Linuxu, slaví 10 let. Vývoj Gitu začal v dubnu 2005. Bylo potřeba nahradit proprietární BitKeeper. Rozhovor s Linusem Torvaldsem o Gitu na Linux.com.
Tiskni
Sdílej:
7.4.2015 00:53
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
.ZIPu, návrat ke starým verzím jen co umí editor přes CTRL+u, či co mám zkopírované ve složce s minulou verzí a tak. Brr.
GIT změnil celé odvětví opensource tak masivně, jako málokterý jiný nástroj. Za to Linusovi patří věčná sláva.
PS: Je mi jasné, že i dřív existovaly nástroje na správu zdrojového kódu, SVN jsem taky chvíli používal, ale ty nehrály takový prim, jako dnes GIT.
nevyjádřil jsem se úplně špatně
Hm, tohle se taky moc nepovedlo. :-)
Pořád přemýšlím, co je na větvení a mergování v Subversion, proboha, tak složitého? Jinak, dost mně práci se Subversion usnadňují RapidSVN, Meld a Subclipse....Mně osobně nejvíc práci usnadňuje, když žádná klikátka používat nemusím. Snad s výjimkou meld, tomu určité výhody rád přiznám, i když uvažuju o tom, že bych se mu taky podíval trochu na zoubek a vylepšil pár věcí.
Pro mě je ale nejlepším verzovacím systémem, jaký jsem kdy potkalJá jsem se Subversion začínal a přechod na Git byl pro mě jako vstup do světa neomezených možností. Ještě na SVN občas se sentimentem vzpomínám, ale v reálu si nemůžu pomoct a dávám přednost git-svn.
Ve stejné době jako Mercurial (možná i o něco dřív, nejsem si teď jistý) vznikl i Bazaar, který byl ze začátku lepší i než Mercurial a rozhodně lepší než první verze Gitu.No to tedy ani náhodou. První verze Bazaaru nebyly nic než vylepšené SVN.
7.4.2015 09:47
GeoRW | skóre: 13
| blog: GeoRW
| Bratislava
Asi ten spor ohladom BitKeeper-u a neexistencie open source CVS nasrdil viacero ludi:
7.4.2015 07:33
8.4.2015 16:09
git checkout -b experiment-foo
git commit ...
git commit ...
git checkout master
# experiment dopadl:
git merge experiment-foo # případně rebase
# experiment nedopadl:
git branch -D experiment-foo
už se staloPozději jsem si všiml, díky, rád si držím přehled o alternativách.
ale vyvozovat z toho co konkurence umí je trochu mimoDělá ti dobře se do mně navážet? Já jen, že mně to nedělá ani dobře ani špatně, jsem na to na ábíčku zvyklý, takže je mi to úplně u prdele a radši se věnuju faktické stránce. To jen takové pošťouchnutí, dál už se k tvým bolístkám nehodlám vyjadřovat.
Ten projekt můžeš naklónovat a experimentovat tam.Ve výjimečných případech, kdy člověk potřebuje duplikovat filesystém a mít zároveň k dispozici checkout různých větví bych to udělal, jinak mi to subjektivně připadá jako nesmysl a filosoficky se to vůbec neshoduje s tím, jak potřebuju pracovat. Je to takové drbání levou nohou za pravým uchem, funguje to, řeší to absenci funkcionality, ale nenazval bych to hezkým řešením.
Branche neuznávám, protože jsou zdvojováním toho co dělá file systém. Adresáře file systému jsou branche projektu.To zavání nepochopením větví, tak jak jsou řešené v Gitu. Osobně pro mě byl Git vysvobozením v tom smyslu, že s větvemi umí nakládat víceméně tak, jak se mi to hodí k práci. Suplování větví adresáří mi připadá absurdní a neefektivní.
Není důvod zasírat repozitář.Branch v Gitu je de facto proměnné pojmenování commitu, repozitář nijak nezasírá. Technicky je to jeden soubor s číslem commitu a prakticky je to jedna linie vývoje s uloženým aktuálním stavem.
nic ve zlýmProč tyhle ošklivé fráze?
nic ve zlým, ale všechno cos tu zatim napsal o mercurialuTy umíš člověka pobavit.
zavání tim že mercurial neznášMožná proto o něm (mimo zvědavých dotazů) nic nepíšu. Pokud tedy nepočítáš mojí mnoho let nevyvrácenou domněnku, že je Git mezi open source systémy nedostižitelný v úpravě patchsetů. Ovšem taková domněnka je lehce vyvratitelná, kdyby ne jinak tak tím, že takový systém někdo napíše a publikuje, ať už bude mít za backend Git, Hg nebo svůj vlastní nový.
sorry, podsunul sem ti že píšeš o mercurialu, když si vlastně psal o všech DVCSDokonce ani ne selektivně o DVCS, nicméně stále se jedná o vyvratitelnou domněnku.
v nějakým konkrétním workflowNikoliv.
Ve výjimečných případech, kdy člověk potřebuje duplikovat filesystém a mít zároveň k dispozici checkout různých větví bych to udělal,Zrovna tohle je vec, kterou bezne pouzivam, a to, ze pro to git nema rozumnou podporu (vice working directories se sdilenym repository), povazuju za (pro mne) nejvetsi nedostatek. Pokud clovek dela na dvou vecech zaroven, tak je daleko jednodussi jen zmenit adresar, nez udelat sekvenci: ulozit docasne zmeny, checkout druhe vetve, obnovit docasne zmeny, make clean, configure, make. Druha vyhoda je ta, ze clovek pri porovnavani zmen neni omezen jen na nastroje, ktere primo podporuji git, a muze pouzit libovolne nastroje pro praci s textem. Zatim to resim nekolika klonama, ale tam je zas otrava v tom, ze nemaji synchronizovanou repository. Nize MarSik upozornil na git new-workdir (diky, to jsem neznal), coz vypada velmi zajimave, ale je to hack treti strany, takze hrozi, ze se to treba rozbije pri upgradu na novejsi verzi gitu.
Zatim to resim nekolika klonama, ale tam je zas otrava v tom, ze nemaji synchronizovanou repository.
A co to udělat tak, že jeden bude klonem druhého (místo centrálního úložiště)? Místo na disku se sice neušetří, ale po síti to budeš tahat jen jednou.
Např. takový Monotone má oddělenou databázi od pracovní kopie a jednu databázi můžeš sdílet z víc míst.
A co to udělat tak, že jeden bude klonem druhého (místo centrálního úložiště)? Místo na disku se sice neušetří, ale po síti to budeš tahat jen jednou.To se obávám, že nebude dost pohodlné. Já osobně jsem měl za to, že více workdirs se sdíleným repozitářem je standardní součásti Gitu (jen jsem to nepotřeboval), ale v tomhle má podle mě Santiago pravdu, že by to chtělo doladit a začlenit. Dokonce si říkám, jestli by pro tyhle lidi (co používají více workdirs) nebyl užitečný workflow s adresářem, který by sloužil jako bare repozitář (ale měl pořád podadresář .git kvůli pořádku) a teprve pod ním by si vytvářeli různě pojmenované pracovní adresáře.
10.4.2015 01:23
git clone v rámci jednoho filesystému jen vytváří hardlinky na původní objekty.
[0] 13:56 vojta ~/tmp/git $ git init
Initialized empty Git repository in /home/vojta/tmp/git/.git/
[0] 13:56 vojta ~/tmp/git $ mv .git repo.git
[0] 13:56 vojta ~/tmp/git $ export GIT_DIR="${PWD}/repo.git"
[0] 13:56 vojta ~/tmp/git $ echo $GIT_DIR
/home/vojta/tmp/git/repo.git
[0] 13:56 vojta ~/tmp/git $ mkdir work-a work-b
[0] 13:57 vojta ~/tmp/git $ cd work-a
[0] 13:57 vojta ~/tm/git/work-a $ echo 'Hello' > hello.txt
[0] 13:57 vojta ~/tm/git/work-a $ git add hello.txt
[0] 13:57 vojta ~/tm/git/work-a $ git commit -m Hello
[master (root-commit) 9f814ec] Hello
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
[0] 13:57 vojta ~/tm/git/work-a $ cd ../work-b
[0] 13:58 vojta ~/tm/git/work-b $ git checkout -f master
Already on 'master'
[0] 13:58 vojta ~/tm/git/work-b $ echo 'World' >> hello.txt
[0] 13:58 vojta ~/tm/git/work-b $ git commit -a -m World
[master e019ee6] World
1 file changed, 1 insertion(+)
[0] 14:01 vojta ~/tm/git/work-b $ git log -p | cat
commit e019ee6e455007dcd8674d9e323743e335762e7d
Date: Fri Apr 10 13:58:49 2015 +0200
World
diff --git a/hello.txt b/hello.txt
index e965047..f9264f7 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1,2 @@
Hello
+World
commit 9f814ec1133b9e87cb8a2d997fb4eb2fec2b8842
Date: Fri Apr 10 13:57:33 2015 +0200
Hello
diff --git a/hello.txt b/hello.txt
new file mode 100644
index 0000000..e965047
--- /dev/null
+++ b/hello.txt
@@ -0,0 +1 @@
+Hello
[0] 14:01 vojta ~/tm/git/work-b $
checkout -f nebo něco podobného.
autor mercurialu razí jedinou myšlenku - dokud svoje věci nezveřejníš, tak si dělej s historií co chceš
To ale dost přesně odpovídá tomu workflow, které popisoval kolega: dokud si na tom pracuju lokálně, můžu si commity libovolně upravovat, přerovnávat, slučovat nebo rozdělovat. Nakonec to buď celé pushnu nebo tu větev smažu (a nebo ji tam prostě nechám být).
hg up -r <hash> hg ci hg ci hg up -r <hash-kam-chci-mergovat> # experiment dopadl hg merge # experiment nedopadl hg strip -r <hash>nevim ale v jakým stavu zůstane git repository, hg repository pak vůbec neobsahuje experimentální changesety
hg help a snažim se to pochopit. strip je rozšíření, jestli to správně chápu, ale vypadá to, že je součástí hg, akorát to asi nemam povolený. Co dělá hned ten první příkaz? Ten <hash> je nějaký existující commit?
nevim ale v jakým stavu zůstane git repository, hg repository pak vůbec neobsahuje experimentální changesetyTo je u toho příkladu s gitem stejný.
[extensions] transplant = rebase = strip = histedit =asi sem právě pochopil proč si tu všichni gitaři myslí že mercurial toho moc neumí; většina novejch věcí v mercurialu začíná tak, že někdo externě spleská extenzi (kterou je nutný si ručně přidat v .hgrc ve formě cesty k .py) a když se to Mackallovi líbí, tak to zařadí do upstreamu, ale zůstává nutnost extenzi zapnout (důvod neznam, možná kvůli kolizi původního .py s jádrem) víc viz http://mercurial.selenic.com/wiki/UsingExtensions jop, hash je commit
asi sem právě pochopil proč si tu všichni gitaři myslí že mercurial toho moc neumí; většina novejch věcí v mercurialu začíná tak, že někdo externě spleská extenzi (kterou je nutný si ručně přidat v .hgrc ve formě cesty k .py)Asi to tak bude; teď jsem narazil na Bookmarks, což vypadá, že dělá něco jako git branches...
…je rozšíření, jestli to správně chápu, ale vypadá to, že je součástí hg
Ano, Mercurial je modulární. Hodně funkcionalit je součástí standardní instalace, ale přitom to jsou moduly (rozšíření), které můžeš ale nemusíš používat, nemusíš je mít ani zapnuté, když nechceš. Plus je spousta modulů třetích stran, od nezávislých autorů.
prakticky každý DVCS backend poskytuje prostředky ke všemu, co se dá s mercurialem dělat, to ovšem není ani dostatečný důvod zvolit jiný tool, ani dostatečný důvod ho považovat pro danou úlohu za rovnocenný.Souhlasím, vždyť jsem psal prakticky to samé, jen s jinou implementací téhož konceptu.
jasně, sem jen anonymní idiotTo slova tvá jsou.
Dokud jsem Git používal jako nástroj k označování změn, aniž bych ty změny cíleně připravoval jako patche nebo commity do správy verzí, tak by mi to bylo dost jedno a stejně dobře bych používal jakýkoli jiný DVCS.My pouzivali hg a pamatuji si, jak to bylo neskutecne pomale a sralo se to. Mozna se to dalo na projekt s par soubory, ale na neco vetsiho to bylo zlo.
To bude spíše rukama.Tak určitě. To je jako když kyknos psal, že jsem na navigaci určitě něco nastavil, abych ji pak mohl neúspěšně reklamovat. :D
Jako jeho největší nevýhodu považuji jeho práci s branchema. Že jsou obravdu neměnné, a táhnou se skrz commity - což ne vždy vyhovuje.
Já to naopak považuji za jednu z jeho velkých výhod. BTW: Mercurial umí oba druhy větví – jak skutečné větve (pojmenovaná část stromu), tak i to, čemu Git říká branch (ve skutečnosti štítek/tag, který se průběžně posouvá).
Přijde mi celkem přirozené, že „větev“ je označením celé té větve a ne jen vrcholku, listu.
adresáři/podstromu
Adresáře (v souborovém systému) a větve (ve verzovacím systému) jsou něco úplně jiného, větve jdou napříč adresáři. Adresáře a větve splývaly možná tak v SVN. Adresáře ve smyslu klony jsou v podstatě třetím druhem větví (ale tam nejde až tak o to, že je to adresář – hlavně je to kompletní klon úložiště a obsahuje všechny jeho adresáře).
hlavně je to kompletní klon úložiště a obsahuje všechny jeho adresáře).Kompletní klon úložiště je záloha. Větev se opravdu dá chápat různě, ale přirozeně bych očekával, že bude představovat dočasnou či trvalou linii vývoje. Neříkám, že to musí být implementováno přesně tak jako v Gitu, ale přijde mi to přinejmenším velmi jednoduché a praktické.
Ať se dívám, jak se dívám, odpověď v tomto komentáři nenalézám, ale co se dá dělat.
To první považuji prostě za „větev“, ale abych to v té větě odlišil od věci, které tu někteří také říkají „větev“ resp. „branch“, tak jsem přidal to „skutečnou“.
To druhé považuji spíš za zvláštní případ štítku (oproti obyčejnému má navíc tu vlastnost, že se při vytvoření nové verze posouvá, jinak to není nic než štítek) a přijde mi trochu matoucí o tom mluvit jako o větvi.
Větev se opravdu dá chápat různě, ale přirozeně bych očekával, že bude představovat dočasnou či trvalou linii vývoje.
No právě – jenže to ten štítek (byť pohyblivý) nesplňuje, protože na základě něj nejsi schopný tu linii zrekonstruovat – nenese s sebou všechny potřebné informace.
Aby nedošlo k mýlce: neříkám, že tyhle pohyblivé štítky jsou špatné, škodlivé nebo že by neměly existovat – to ne – mají a existuje pro ně smysluplné využití, jen prostě nejsou plnohodnotnou náhradou větví – je to úplně něco jiného. Je to asi jako pevný disk a RAMka nebo jako struktury seznam a mapa – každé z toho má svoje využití a jedno není plnohodnotnou náhradou toho druhého. Proto jsem rád, že Mercurial poskytuje oboje.
A neni to v pripade stromu ekvivalentni - z korene do listu vede vzdy jen jedna vetev, proto urcenim listu urcim jednoznacne i tu vetev.Přijde mi celkem přirozené, že „větev“ je označením celé té větve a ne jen vrcholku, listu.
Asi mluvíme každý o něčem jiném. Já mluvil o grafu generovaném relací rodič - potomek mezi jednotlivými commity. Merge commit má rodičů víc, takže nejde o strom.Je to DAG. Což mimochodem platí i pro Mercurial, takže větev v Mercurialu není o nic lépe definovaná než v gitu, resp. lepší by bylo říct, že v gitu není definovaná o nic hůře
Je to DAG.Pravda. Navíc to platí pro oba případy, tedy nezáleží na tom, zda diskuzi chápeš tak jako já nebo tak jako Michal, stejně jako pro celý gitovský object store.
Právě že není. Jednak to není strom, jak už tu padlo. A jednak z listu/vrcholu nejsi schopný dohledat celou tu větev, rozpoznat hranice mezi větvemi a rozlišit, co je „kmen“ a co jeho „větev“.
Je to např. takhle?
/--------c a---*------b
a nebo takhle?
a---*---------c
\-----b
Když znáš jen vrcholy resp. body a,b,c, tak to nejde rozlišit.
z listu/vrcholu nejsi schopný dohledat celou tu větev
Jsem. Do větve patří všechno, co z příslušného commitu dostanu, když půjdu po rodičích. Jak už jsem psal, není to obecně lineární posloupnost commitů, ale to je jen jedna z věcí, na které je potřeba si zvyknout.
rozpoznat hranice mezi větvemi
To byste musel nejdřív nadefinovat, co to ta hranice má být.
rozlišit, co je „kmen“ a co jeho „větev“
Trik je v tom, že to potřeba rozlišovat není. Ty dva obrázky jsou ekvivalentní a v obou mohu udělat merge b do c stejně jako merge c do b. Co víc, ať už "původní" větev byla kterákoli, pro oba merge existuje use case, kdy dávají velmi dobrý smysl. Takže proč rozlišovat, která je "hlavní" a která je "z ní odvětvená"?
A jednak zWTF?listu/vrcholu nejsi schopný dohledat celou tu větev
rozlišit, co je „kmen“ a co jeho „větev“.Metafora stromu v datových strukturách takto ovšem vůbec nefunguje a co je „kmen“ pokud vím záleží jen na workflow a vyjadřuje se (dočasným) pojmenováním těch větví na dobu, kdy to rozlišovat potřebuješ. Obávám se, že tady v diskuzi ještě nepadla ani definice větve, která by něco takového vyžadovala, takže by bylo fajn takovou definici uvést, ať si na ni člověk může alespoň udělat názor.
Když znáš jen vrcholy resp. body a,b,c, tak to nejde rozlišit.V Gitu se to bere tak, že větev a je tvořena všemy commity od počátku po a, b od počátku po b, atd. Tzn. jestliže v tom tvém grafu je a počátek (init) a, pak větev c tvoří commity a..c a větev b commity a..b, tzn. ten úsek od a po to rozvojení je společný oběma vetvím. V Mercurialu to AFAIK tak není - ie. ten úsek a..rozdvojení bude patřit jedný nebo druhý, ale osobně mi to nepřijde jako podstatné. Byl by nějaký příklad / use case, kdy to je užitečný?
7.4.2015 12:22
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha