Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
git stash
(uložení rozpracovaného stavu na zásobník, vrátí se to git stash pop
) a commituji potom.
git commmit -a -m 'WIP'
rebase --autosquash
), akorát si člověk musí dát pozor, aby neopakoval stejnou commit message vícekrát, protože fixup commit se váže na commit message, ne na hash (což mi přijde jako blbý rozhodnutí, ale nic s tim neudělám).
git add -i
je určitě fajn, ale git gui
umožňuje stagovat s vyšší granularitou (jednotlivé řádky).
protože fixup commit se váže na commit message, ne na hash (což mi přijde jako blbý rozhodnutí, ale nic s tim neudělám).Protoze to ma implikace, ze pak musis umet ty fixup commity mit svazane s tim fixovanym, i kdyz udelas treba rebase bez toho autosqashe, atp. A muj tip je, ze kdyz se tim smerem vydas, tak skoncis zpatky ve stavu, ze ktereho si vysel. Ze nejjednodusi (mozna i jedinny) zpusob, jak toho dosahnout, je normalni commit se specialnim jmenem. A trochu se obavam, ze neco podobneho by se ti stalo i s tim zasobnikem, kde by to vlastne bylo to same akorat by to byla fixup vetev.
Protoze to ma implikace, ze pak musis umet ty fixup commity mit svazane s tim fixovanym, i kdyz udelas treba rebase bez toho autosqashe, atp.Rebase by to mohl celkem snadno umět aktualizovat, stejně už IIRC upravuje časový razítko u všech commitů... A u nějakýho jinýho způsobu úpravy historie by to bylo holt na tobě. Ale souhlasim, že to je implementačně/koncepčně složitější...
akorát si člověk musí dát pozor, aby neopakoval stejnou commit message vícekrát
Celý commit message stejný, to je při rozumně napsaných prakticky nemožné, pokud nejde o cherry pick. I úplně stejný subject je na pováženou, pokud je to v jedné sérii.
git add -i
commitnut samostatne len niektore riadky z prveho hunku a asi by bolo treba pouzit git add -e
, co uz zacina byt trochu komplikovane.
Neverim, ze niekto kto pouziva Emacs este o Magite nepocul, ale ak niekto uvazuje Emacs skusit, tak uz len pre ten Magit by som odporucal tomu dat sancu napriklad s niecim ako Doom Emacs.
git add -i
" mi k srdci nepřirostl a i když jsem se mu párkrát snažil dát šanci, "git gui
" je z hlediska uživatelského komfortu úplně jiná liga.
90% času tohle potřebuji řešit na vzdáleném stroji s minimalistickou instalací
Pak je asi na místě otázka, jestli je rozumné ten git spouštět přímo tam. Já jsem třeba poměrně dlouho z lenosti z domova používal git na počítači v práci (včetně "git gui
" přes "ssh -X
") a teprve to, že jsem dočasně musel používat jiný VPN endpoint, a s tím související nárůst latencí mne donutil zařídit si to tak, abych tohle dělat nemusel. S odstupem času je to samozřejmě praktičtější, ale kdyby mne k tomu nedonutily okolnosti, nejspíš bych to tím krkolomným způsobem dělal dodnes.
Situace že by se mi těsně vedle sebe sešly dvě různé věci, tak že by je bylo nutné separovat po řádcích, je pro mne velmi nepravděpodobné.
Mně se to naopak děje docela často. Což ale možná souvisí s…
Důležitý je pro mne commit komplexní změny.
Commit by právě pokud možno moc komplexní být neměl. Naopak, měla by to být co nejmenší změna, která sama o sobě ještě dává smysl. Jak kdysi podotkl jeden maintainer, pokud píšete commit message a chystáte se začít větu slovem "Also", je to obvykle znamení, že byste měl commit rozdělit.
Pak je asi na místě otázka, jestli je rozumné ten git spouštět přímo tam.To teda rozhodně je Je to nejrychlejší způsob, jak zjistit jestli, nebo kdy někde nastala nějaká nežádoucí změna. Často toho využívám při dohledávání změn realizovaných někdy v minulosti.
git add -i
jsem ani neznal. Osobně používám git add -p
(případně i s cestou), který spustí rovnou tu interaktivní "patchovací" část.
Tiskni Sdílej: