git - popis vývojové větve

11.3.2018 15:16 | Přečteno: 2245× | Za vším hledej Linux |

Bez verzování přes git bych v současné době při mém stylu práce asi nemohl existovat. Bohužel má původní snaha commitovat do gitu jen ucelené změny, vzala brzy za své. Většinou to vypadá tak, že mám něco rozdělané, ale musím toho nechat, abych mohl začít řešit něco jiného. A když se k tomu po nějakém čase vrátím, tak mi visí změny, o jejichž smyslu už mám jen matné tušení. Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?

Většinou to tedy dopadne tak, že uložím všechny změny které visí do jednoho nic neříkajícího commitu, abych se ni ni mohl přepnout a pak se k rozdělané práci vrátím doufaje, že to snad dotáhnu do stavu, který by bylo možné alespoň s trochou snahy považovat za použitelný. To se však podaří jen málokdy, protože se mezi tím rozdrbe zase něco jiného. V takových situacích se vracím do stavu kdy příslušná věc byla prokazatelně funkční tím, že z příslušného commitu vytvořím novou větev.

Pokud na něčem dělá člověk sám, tak v tom zpravidla nebývá problém. Horší je to v situaci, kdy nějakým způsobem využívá jiný projekt, který prochází obdobně bouřlivým vývojem. A tak jsem začal mít pocit, že už jsem se v těch větvích začínal ztrácet. Ze stručného pojmenování větve totiž lze jen málokdy vydedukovat za jakým účelem byla vlastně vytvořena. A tak mne napadlo se podívat, jakým způsobem se dá k nějaké větvi git repozitáře přidat podrobnější popis.

Je to jednoduché. Stručný popis pro každou z existujících větví lze přidat prostřednictvím příkazového řádku:

git config branch.master.description "Popis k hlavní vývojové větvi".

Tímto příkazem se do sekce větve master v souboru .git/config přidá atribut description s obsahem "Popis k hlavní vývojové větvi". Existující popis lze kdykoliv nahradit jiným, případně ho dodatečně upravit příkazem:

git branch --edit-description

Popis může být i víceřádkový. Součástí řetězce v souboru .git/config pak bude i sekvence pro zalomení řádku.

Poněkud nešikovný je však způsob zobrazení popisu. By default totiž git vypisuje pouze seznam existujících větví, bez popisu. Pokud vás zajímají i popisy příslušných větví, musíte se na ně dotazovat jednotlivě, stejným příkazem, jakým se popis přidává, ovšem bez toho, že by mu byl předán textový řetězec.

git config branch.<jméno větve>.description

Pro ty co by rádi viděli tyto výpisy vypsané rovnou v seznamu existujících větví existuje shellový wrapper branches.sh, který napsal Gleb Bahmutov, z jehož blogpostu jsem čerpal.

       

Komentáře

[xkucf03]

Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?

K tomu slouží git stash – je to něco jako kdyby sis udělal git diff výsledek pojmenoval a někam uložil pro budoucí použití a změny v pracovním adresáři zahodil. Udělat klasický git commit (--amend), je taky cesta, ale tam hrozí, že člověk na rozdělanou práci zapomene a omylem udělá git push.

Popis může být i víceřádkový. Součástí řetězce v souboru .git/config pak bude i sekvence pro zalomení řádku.

Ty popisy jsou ale jen lokální, ostatní je nevidí, ne? Při týmové práci bych spíš větev pojmenoval podle čísla úkolu ze systému na správu chyb/požadavků (Bugzilla atd.) a podrobný popis měl tam.

[Aleš Kapica]

Ty popisy jsou ale jen lokální, ostatní je nevidí, ne?

Ano. Ale to je přesně to, co jsem od toho očekával. Ty popisy jsou určeny především pro mne, abych si po čase snáz vzpoměl proč jsem onu branch buď já, nebo autor aplikace vlastně založil. Někdy samozřejmě stačí pouhé pojmenování větve, ale v některých případech ne.

Navíc nemám ambice, ani čas na to, abych participoval na vývoji kdejaké aplikace. Pokud potřebuji vyřešit nějaký problém, založím si branch, pro sebe problém vyřeším a pokud to má valný smysl i pro někoho jiného, pošlu autorovi patch a nechám zcela na jeho libovůli jak s ním naloží.

[Josef Kufner]

Řešení je jednoduché: Nepoužívej k vývoji hlavní vývojovou větev (master).

Než něco začneš dělat, tak si udělej feature branch, typicky vytvořenou z nějakého issue (Gitlab na to má dokonce čudlík). Pak něco chvilku děláš na té feature branch a když je ta jedna věc hotova, tak se to mergne do masteru. WIP commit s poznámkama na konci takové větve nevadí. Mezitím můžeš v klidu přepínat na funkční master a přidávat malé opravy na relativně stabilní kód.

Když dělá na projektu více lidí, tak si každý hraje ve své feature větvi a lidi si navzájem nepřekážejí. Hezky to také funguje s merge requesty a code review.

[Doli]

Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?

git fetch stáhne změny z remote, aniž by cokoliv měnil v lokálním repu.

[KS]

Nebo přepnout pomocí git worktree.

[xkucf03]

BTW: jak řešíte situaci, kdy si chcete zazálohovat vzdálený git? A tím myslím kompletně – všechny větve.

[Josef Kufner]

Prostě to naklonuješ:

       --mirror
           Set up a mirror of the source repository. This implies --bare. Compared to
           --bare, --mirror not only maps local branches of the source to local branches
           of the target, it maps all refs (including remote-tracking branches, notes
           etc.) and sets up a refspec configuration such that all these refs are
           overwritten by a git remote update in the target repository.

[xkucf03]

A následný pull/fetch přes všechny větve?

[Michal Kubeček]

Stačí fetch, pull je jen zkratka pro fetch + merge a ten merge už můžete udělat lokálně. Takhle to třeba řeším na notebooku, kde je dobré mít fetchnutý co nejvíc akutální stav, ale není nutné mít aktuální i lokální tracking branche, protože to už můžu v případě potřeby udělat i offline. Takže když jsem online, pustím něco jako

  for d in ~/work/git/*; do git -C "$d" fetch --all; done

a update lokálních větví nechám až na moment, kdy je opravdu chci použít.

[xkucf03]

Mně právě někdy přišlo, že git nepostahuje všechno, ani když dám fetch --all. Ale teď jsem to zkoušel a vypadá to OK.

[dementni.lojzik]

pokud chces, aby se ti to stahovalo pokazde jen pres git fetch, tak by melo stacit do .git/config dat neco jako

[remote "upstream"]
        url = $REPO
        fetch = +refs/heads/*:refs/remotes/upstream/*

Takhle jsou automaticky napr. z githubu stahovat i pull requesty do prislusne vetve

[remote "upstream"]
        url = $REPO
        fetch = +refs/heads/*:refs/remotes/upstream/*
        fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

[vencour]

Přidal jsem do výběru.

[Bedňa]

Git spravuje verzie, to že nedokončuješ svoju prácu je tvoj problém. Na to je dobré nasadiť Git + niečo. Napr. taký GitHub má Issues, kde si aj sám môžeš napísať, čo tam treba dorobiť.

Vlastne by stačilo urobiť niečo na spôsob GitHub issues, kde si budeš písať poznámky k branchom kde si skončil a čo to malo pôvodne robiť.

Git robí svoju prácu dobre, na tebe záleží ako si spravíš svoje nástroje nad tým postavené.

[Aleš Kapica]

Nechápu smysl tvého sdělení. Samozřejmě že git dělá svoji práci dobře. Jinak bych ho už víc jak deset let nepoužíval.

Jinak jak jsi správně podotknul, můj pracovní workflow je také čistě můj problém. Do vývoje aplikací zasahuji z dobré vůle, ne proto že by mě za to někdo platil, nebo že bych z toho něco měl. Nejsem typ multitaskingového člověka, který je schopen se plynule přepínat mezi úlohami a pokaždé bez problémů navázat. Potřebuji na věc plně soustředit.

To je ostatně důvod, proč na abclinuxu také aktivně přispívám do diskuze. Někomu stačí k odreagování si sem tam něco přečíst. Ovšem bez toho, že bych čs od času v diskuzi nezareagoval by se mi v kupř. v hlavě honilo: "Panebože ten XY je snad úplný kretén?" nebo "Proč to nezkusí vyřešit taky takhle?". Takže si během pár sekund vyčistím hlavu. Někoho moje reakce pobaví či navede správným směrem, jiného nasere, ale já se můžu soustředit na práci.

[Bedňa]

Jako OK kámo, nič v zlom, len som písal, že pre tvoje potreeby by bolo lepšie postaviť nad Gitom niečo, kde si sám budeš písať ciele a poznámky. GitHub to má priamo v sebe.

[xkucf03]

GitHub je proprietární služba. Když už tak něco jako GitLab, Kallithea atd. A nebo pak třeba Fossil, což je verzovací systém, který má vestavěnou wiki i správu chyb/požadavků.

[Bedňa]

Rovnako uprednostňujem slobodný softvér, mno zrovna to čo si vymenoval nieje úplne adekvátna náhrada, to skôr Gitea. Hoci Fossil nepoznám, ale mrknem na to.

[kralyk z abclinuxu]

GitHub je proprietární služba.

To je sice pravda, ale na GitHubu ani tak nejde o tu službu, jako spíš o tu komunitu a viditelnost. Pro vlastní účely si člověk určitě může nahodit GitLab nebo cokoli jinýho, ale imho veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu. Může se nám to nelíbit, ale je to tak ...

[Josef Kufner]

Mirror na GitHubu je v pohodě, ale primární repozitář s issues je lepší mít více pod kontrolou. Pro malé projekty to je asi jedno, ale pro něco většího a dlouhodobějšího už to má smysl řešit.

[xkucf03]

Aby moje předchozí tvrzení neznělo tak radikálně: zrovna u distribuovaných verzovacích systémů není proprietární služba resp. hosting až taková tragédie, protože úložiště se dá kdykoli naklonovat, vystavit jinde a uživatelé si jen změní URL. Taky nehrozí ztráta dat, protože autoři mají všechno i u sebe. A integritu lze zajistit elektronickým podpisem jednotlivých verzí.

Nicméně i přesto mi to trochu vadí a považuji to za problém (i když jsou mnohem horší věci). Např. jde o to, že s GitHubem musíš uzavřít smlouvu, vzdát se různých práv a k jiným věcem se zase zavázat. Prostě typické právnické sračky jako u jiného proprietárního softwaru. Taky to běží v USA a podléhá jejich právu (patenty, jejich výklad copyrightu…).

veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu

A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní… A zrovna u distribuovaného verzovacího systému je to vážně hloupé a zbytečné – jeho zásadní vlastností je právě ta distribuovanost/decentralizace. A nutnost mít účet u jednoho konkrétního poskytovatele gitového hostingu jde přímo proti této myšlence.

Mělo by být jedno, kde je ten repozitář uložený – technologie to podporuje. A pokud jsou potřeba nějaké dodatečné funkce (úkoly, pull requesty, wiki, statistiky atd.), měl by je pokrývat svobodný software – ne proprietární služba.

[xkucf03]

s GitHubem musíš uzavřít smlouvu

Jde to řešit tak, že si vytvoříš falešnou identitu, nějakého svého virtuálního kolegu, který s GitHubem tu smlouvu uzavře, a bude dělat pravidelně git push a git pull a synchronizovat tak úložiště. Primární ale musí být u tebe a vždy musíš být připraven na to, že hosting na GitHubu může kdykoli skončit. Ten kolega bude ve skutečnosti robot a to, že uzavřeli smlouvu s robotem je jejich problém nikoli tvůj.

Na tyhle proprietární služby bych se nespoléhal, je to stejný případ jako třeba YouTube nebo Facebook – jsou lidé, kteří si tam vybudovali síť přátel/kontaktů a pak o ni jednoho dne přišli, protože se provozovateli nelíbil nějaký jejich obsah nebo se třeba jen nějaký jejich pracovník spletl. Komunikace s takovou korporací a snaha o nápravu je jen ztráta času. Viděl jsem např. lidi doporučující si budovat i paralelní síť přátel na VK.com. Ale to je trochu z bláta do louže (záleží taky na politických postojích a možných konfliktech zájmů).

Tak jako tak si člověk musí udržovat záložní komunikační kanál pro případ problémů. Jenže když už člověk tu záložní infrastrukturu má, tak proč ji nepoužít rovnou jako primární místo té proprietární služby? Kvůli šířce pásma a lepšímu pingu do různých částí světa? Kolik dat vlastně potřebujete hostovat a jakou latenci vyžadujete, aby tento argument byl vůbec relevantní?

[Michal Kubeček]

Čas od času mne přepadnou pochybnosti, jestli to s tou nekonformností a paranoiou už trochu nepřeháním. Pak zajdu na ABCLinuxu a to mne spolehlivě uklidní… :-)

[kralyk z abclinuxu]

Asi tak

[kralyk z abclinuxu]

A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní…

Ano, tak to funguje. Viz network effect / bandwagon effect.

Přijde mi, že diskuse, jestli to je nebo není špatně je tak trochu bezpředmětná. Já taky mam samozřejmě radší svobodné služby oproti proprietárním. Terms & conditions, NDA a podobně se mi taky nelíbí. Na úrovni teorie souhlasim s těmi ideály o svobodných decentralizovaných slulžbách, nicméně reálně to jde celé do kopru ve chvíli, když si spočteš, že pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešení. (Inb4 elitistické racionalizace á la "Uživatel, který nechce reportovat do našeho systému nám nestojí za to a stejně nejspíš píše blbý bugerporty.")

Časy ICQ ti to přípomíná správně, ty časy se nijak nezměnily. ICQ nebylo nahrazeno Jabberem, nýbrž Facebookem. A jestli něco nahradí Facebook, nejspíš to zase bude nějaká proprietární centralizovaná služba spíš než nějaká Diaspora nebo podobné softwary, které jsou sice docela hezké, ale bohužel šanci na reálné využití mají mizivou (a to i přesto, že existují lokální extrémy).

Nejsem nijak proti svobodným alternativám populárních služeb, občas je zkoušim, ale v jejich úspěch moc nevěřim. Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...

[xkucf03]

Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...

Zrovna vedle na Rootu: Londýnský starosta na SXSW 2018: technologické firmy nejsou nad zákonem:

Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách. … Pokud sítě jako Facebook, Twitter či YouTube a další nevezmou existující problémy vážně, může je potkat regulace ze strany vlád. V tomto kontextu připomněl nedávné úpravy zákonů v Německu, které umožňují pokutovat provozovatele sítí až 50 milióny eur, pokud neodstraní hanlivý příspěvek do 24 hodin. Khan by nerad viděl, aby to (regulace) zašlo tak daleko, neb tyto formy regulace nejsou v souladu se svobodou projevu.

Decentralizovaná sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet… Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.

Nebo: Vlády přesměrovávají uživatele na software doplněný o malware:

Avast, CCleaner, VLC, Opera, 7-Zip a další populární aplikace. Pokud se je pokusíte stáhnout v Turecku, dostanete k nim zvláštní dárek – malware. … Turecko se svým poskytovatelem Türk Telekom však není jedinou zemí, kde byla tato praktika objevena. Stejné zařízení pro zkoumání provozu bylo objeveno také v Egyptě u společnosti Telekom Egypt.

Německo, Turecko, Británie, Egypt a další země… tyhle nezdravé myšlenky popírající svobodu se šíří všude možně, takže si nemyslím, že jde o nějakou přehnanou paranoiu.

[kralyk z abclinuxu]

Decentralizované sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet…

V čem je výhoda sítě, která je decentralizovaná, liberální a necenzurovaná, ale na které nikdo není? Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí?

Čimž určitě nechci schvalovat cenzuru sociálních sítí ze strany státu, jenom mi není jasný, v čem je praktická hodnota toho tvého tvrzení. IMHO pravděpodobně má mnohem větší šanci na úspěch snaha o nastavení smysluplnějších pravidel pro Facebook než snaha o protlačení Diaspory apod.

*) Tímto se omlouvám davkolovi, který byl tuším můj jediný kontakt na Diaspoře, když jsem ji zkoušel používat.

Nebo: Vlády přesměrovávají uživatele na software doplněný o malware

V čem je pointa? Repozitář mého distra je v zásadě centralizovaný, stejně jako repozitáře ostatních dister. Ten odkaz je prostě akorát o tom, že Turecko není právní stát a stojí to tam za *****.

[xkucf03]

Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí?

S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli. Publikovat tam nějaký užitečný obsah (tzn. poskytnout provozovateli práva, licenci, svoje data…) dává smysl leda za účelem získání těch příznivců. Takže tyhle sítě jsou dobré leda tak pro různé kremloboty/euroboty/sorošboty/aláhoboty a podobné. A do toho tam pumpují explicitní nebo častěji skrytou/neoznačenou reklamu různé firmy a dotují různé tragédy a klauny, smyslem jejichž existence je získat „popularitu“ a příznivce a pak šířit reklamu pro toho, kdo zrovna platí.

[kralyk z abclinuxu]

S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli.

Ok, kterou sociální síť doporučuješ na kontakt s přáteli?

[xkucf03]

Pro 1:1 klasicky e-mail a Jabber (pokud možno šifrovat). A pro m:n komunikaci opět klasické blogy, RSS/Atom a servery typu Ábíčko nebo různé komunitní weby.

Webové videokonference fungují pěkně na meet.jit.si. (zatím jsem nezkoumal, jak je to tam s odposlechem, ale neříkal jsem tam nic důvěrného, co bych neříkal na veřejném místě, jako je třeba hospoda nebo tramvajová zastávka)

[kralyk z abclinuxu]

Ani jedno z toho není sociální síť. Nejblíž k tomu má Ábíčko, na kterém ale nejsou moji přátelé (resp. nějací jo, ale jen hodně malá část a ubývá to). Jabber používá málo lidí dokonce i z těch technicky zaměřených.

[kralyk z abclinuxu]

Abych to upřesnil, u těhle služeb / poskytovatelů / atd., kde jde z velké části nebo primárně o komunikaci, je hodně důležitý ten network effect - ten tam dělá velkou část nebo i většinu té hodnoty. IMHO ho nejde jen tak ignorovat a řešit jen technické vlastnosti, protože sebelepší technické vlastnosti ti bez network efektu k ničemu moc nejsou dobrý. Viz tohle xkcd.

[xkucf03]

To záleží, jak definuješ sociální sítě. Ze společenského pohledu jsou to okruhy tvých přátel a známých¹. Z pohledu IT je to pak nějaká technologie/platforma, která ti umožňuje s těmito lidmi komunikovat a to buď 1:1 nebo 1:N.

Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).

_{[1] rodina, sousedi, spolužáci z různých škol, kolegové z různých prací, kamarádi z různých sportů a kroužků, náhodní lidé, které jsi potkal atd.}

[kralyk z abclinuxu]

Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).

Webový prohlížeč mají všichni ale svůj vlastní web nemají a nebudou ho mít. Dále ani web ani e-mail nemají to UI, které by se vyrovnalo té sociální síti. E-mail pokrývá pouze relativně malou podmnožinu té funkcionality.

[Heron]

Kdysi jsem napsal článek o tom, že sociální sítě jsou jen taková lepší RSS čtečka. To totiž záleží na tom, jak je používáš. Já a celá moje bublina to používá způsobem pro sdělení one to many, většinou dávají odkaz na nějaký web a k tomu napíší svůj názor. (Takže je to vlastně odkaz na článek s komentářem od kámoše.)

Někdy se pod tím odkazem vytvoří více či méně hodnotná diskuse, která je určitě přínosem. Jen je škoda, že se většinou vede diskuse na sociální síti a nikoliv pod článkem samotným.

Ano, i já považuji za nejlepší způsob 1:1 komunikace email a taky se mi to daří provozovat, s určitými lidmi si píšeme mnohostránkové emaily, což je něco, co se na sociální sítě docela blbě umisťuje. Jistě bych byl raději, kdyby to psali někam na veřejný blog, ale ne každý je této povahy.

[kralyk z abclinuxu]

Kdysi jsem napsal článek o tom, že sociální sítě jsou jen taková lepší RSS čtečka.

Třeba Facebook v tomhle režimu používám z relativně malé části. Usecase "RSS čtečka" je vhodná na veřejný obsah. (Navíc popravdě RSS čtečky mi nikdy k srdci moc nepřirostly a jsou orientované na technicky zaměřené lidi.)

Pro mě přínos FB je asi v těhle věcech:

• Sdělení 1:N, které ale nemá být úplně veřejné. ("Čau, nechystáte se někdo jet tam a tam nebo udělat to a to? Měl bych zájem o tohle a tohle ..." atd. atp.)
• Události, a to hlavně opět neveřejné, ale pro nějakou skupinu. Na organizování nějaké společné akce s kámošema je to dost bezkonkurenční.
• Zájmové skupiny, opět třeba ne úplně veřejné (měli jsme skupinu školního kruhu, kolejní skupinu, atd.)
• Celkem dobrý IM
• Výše zmíněné featury jsou spolu integrované. V tom vidím podobný přínos jako třeba použití IDE nebo příkazové řádky slušného OS, kde ty věci jsou na sebe navzájem navázané.

Samozřejmě většina těch věcí výše by se dala nějakým způsobem nahradit, alespoň s technického hlediska, ale zase: o tom to tak úplně není.

Co se týče e-mailu, taky ho používám i na komunikaci s kamarády / rodinou. Teďka mam dokonce čerstvou zkušenost, kdy jsem jednu akci pro kamarády organizoval přes e-mail a jednu na FB. Obojí má svoje pro a proti. Na tom FB mi to ale přijde snazší a je to přehlednější - problém s e-mailem je, že je v zásadě bezstavový.

[Heron]

veřejný obsah

No já FB používám výhradně jen na veřejný obsah. Jsou sice lidé, kteří mi píší na FB IM ale i tam se snažím mít na paměti (což se teda ne vždy povede...), že to fakt není soukromá komunikace a že to může kdykoliv kdokoliv číst. Ale jinak žádný obsah se sníženou viditelností netvořím, vše veřejné. Jsem i členem několika uzavřených skupin, ale i tam je tolik lidí, že je to taky v podstatě veřejné (a asi to je teda i veřejně vidět, jen to nečlenové nemohou komentovat).

Co se týče toho organizování akcí, no já jsem dost paranoidní na to, abych dopředu "veřejně" oznámil kdy a na jak dlouho patrně nebudu doma. A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.

[kralyk z abclinuxu]

A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.

Soukromou událost na FB vidí pouze ti pozvaní (což třeba v mém aktuálním případě dělá ~10 lidí) a nikdo jiný vůbec nevidí ani tu událost ani jestli se ji někdo účastní nebo ne ani nemají možnost ji "sdílet" nebo whatever, prostě se k tomu fakt dostanou jen ti pozvaní.

[snajpa]

No, kdyz je na tom FB pekne podokumentovana, tak zas tak soukroma neni, ze jo.

[kralyk z abclinuxu]

?

Jak se to liší od organizace události po e-mailu? Šance, že někdo z tvých kamarádů má gmail nebo něco podobného je hodně velká. Takže ten rozdíl je reálně akorát v tom, že na tom FB je to dokumentované u FB, zatímco po e-mailu to je dokumentované u Googlu, Seznamu a pár dalších firem.

[ehm]

Co ti brání ty zprávy šifrovat?

[kralyk z abclinuxu]

Chci vidět mé ne-technické kamarády, jak šifrují e-mail ...

[ehm]

Nauč je to.

[kralyk z abclinuxu]

Lol, tak určitě. Do toho by se nejspíš nechtělo ani těm technicky založeným. O ne-technických povahách nemluvě.

[ehm]

Pak je to možná zbytečně složité. Co řešit, jak to zjednodušit?

[snajpa]

Slozity je predevsim key & trust management, to neni zvladnute dostatecne BFU-friendly, resp. nevidel jsem uspesny priklad.

[trekker.dk]

Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách.

Zajímavé, on existuje nějaký zákon, který by jim něco takového nařizoval? Jestli ono to nebude spíš "tady je něco, na co my politici nemáme takový vliv, jaký bychom chtěli"

[Heron]

Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.

S tou anonymitou bych to zase tak nepřeháněl, určitě ne hned v začátku. Podle mě je správné* podepsat své názory, stát (strašné slovo) si za tím, dokázat je obhájit slušným způsobem apod. Pokud je to anonymní výkřik, tak nemá zkrátka takovou váhu a navíc nikdy nevíš, zda to někdo neříkal z postranních důvodů.

Podle mě je místo pro anonymizaci skutečně až ve chvíli, kdy za názor hrozí kulka do hlavy. V takových režimech jsou anonymní nástroje jistě přínosem, pokud jsou ovšem používány pro pravdivé informování o stavu v takové společnosti nebo režimu. Ani tady příliš nepomůžou výkřiky, které nejsou pravdivé.

*) Jako jak jinak chceš budovat slušnou občanskou společnost, pokud budou všichni anonymní a Tonda nebude vědět, že stejné názory má i Karel odvedle, se kterým se na anonymních fórech vlastně shoduje? Prostě podle mého přesvědčení je potřeba anonymitu používat skutečně jen ve výjimečných případech a snažit se dostat do stavu, kdy už nebude potřeba.

[xkucf03]

Proto jsem psal anonymita/pseudonymita. Na to, abys podpořil nějaký názor autoritou svojí osoby, není potřeba, aby ostatní znali tvoji fyzickou identitu – stačí, aby si dokázali daný výrok/názor spojit s tvými dřívějšími projevy a dát si ho do kontextu. Naopak na tom internetu je mnohem užitečnější znát ten internetový pseudonym než znát občanské jméno a bydliště – např. komentář, který psal uživatel Heron pro mě má větší váhu než komentář, který psal např. Jan Zahradník z Frýdku-Místku registrovaný pod číslem 197611, který se nechal ověřit doporučeným dopisem a SMSkou a který o sobě vyžvanil i jméno babičky za svobodna a přiložil fotokopii vysvědčení ze základky.

Podpis beru jako součást projevu – stejně jako jazyk, styl nebo formu – a je na autorovi, jak a jestli se podepíše, jak moc propojí daný výrok se svojí internetovou nebo dokonce fyzickou identitou. A právo ostatních zase je, číst, co jim vyhovuje a přisuzovat tomu váhu i podle toho jak a kdo to podepsal – např. můžou zcela ignorovat anonymní příspěvky nebo příspěvky od neznámých pseudonymů. Různé druhy podpisu mají svoje výhody a nevýhody a nemyslím si, že by měla existovat nějaká obecná norma, jak se to má dělat.

[ehm]

pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešení

A není to spíš jeho problém? Založit ticket v self-hosted Bugzille nebo poslat bugreport mailem fakt není o moc složitější než založit issue na GitHubu. Pokud mu to nestojí za to, ať si klidně dál používá zabugovaný software, nebo najde nějakou alternativu. FOSS přece člověk píše zpravidla hlavně pro sebe a je jeho dobrou vůlí dávat to zdarma k dispozici ostatním. Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut?

Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod.

Kdyby se GitHub používal opravdu jen jako hosting pro git repozitáře, přičemž přechod na jinou službu by spočíval jen v nahrazení URL repozitáře na webu za jinou, tak bych s tím tak velký problém neměl. Otázkou pak je, proč něco takového dělat, když hostovat repozitář lze i na vlastním serveru, a to naprosto triviálně. Navíc lze vytvořit i soukromý repozitář, aniž by za něj bylo třeba platit (jako na GitHubu). A máš nad tím kompletní kontrolu ty, ne třetí strana, která se snaží tvářit, že je hodná, ale vždy se bude orientovat především na finanční zisk; a i kdyby ji zatím vlastnil nějaký moralistický idealista, vše se může změnit se změnou vlastníka.

[xkucf03]

+1

Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém.

A teď si to spoj s tím, že státy dělají MITM útoky a podstrkávají uživatelům mallware. Pokud jediný kontakt na autora softwaru, který máš, je URL na GitHubu a nemáš ani otisky jeho GPG veřejných klíčů, tak vládě stačí zatlačit na jednu firmu a může uživatelům okamžitě distribuovat škodlivý software. Neříkám, že napadnout libovolného poskytovatele domén a hostingu nejde – jasně, že to jde, ale těch poskytovatelů jsou spousty, mají různou míru (ne)ochoty spolupracovat a různou míru odvahy dát o tom svinstvu vědět veřejnosti. Kdežto, když je všechno v jednom centru, u jednoho subjektu, tak to má útočník mnohem jednodušší a šance na odhalení se snižuje.

[kralyk z abclinuxu]

Kolik lidí má tvůj GPG klíč a GPG klíče kolika vývojářů máš ty?

[xkucf03]

Málo. Ale pointa byla v tom, že když je něco centralizované, je to snáze napadnutelné a snáze se dá útok utajit, než když by se útočník měl „dohodnout“ se spoustou malých subjektů – u nich je větší pravděpodobnost, že někdo z nich o útoku alespoň řekne veřejnosti.

[kralyk z abclinuxu]

Pointě nerozumim. Resp. přijde mi zřejmá - to taknějak plyne přímo z definice (de)centralizovanosti.

[xkucf03]

V té velké korporaci o tom může vědět třeba jen pár lidí – zatímco většina zaměstnanců vůbec nic netuší (pro ně to jsou jen nějaké automatizované procesy, uzly v síti nebo krabice v serverovně, kam nemají přístup – ale na tom není nic divného, protože v korporaci je spousta míst, kam nemají přístup). Kdežto v té malé firmě/organizaci o tom bude vědět taky jen pár lidí, ale tam těch „pár lidí“ = třeba polovina nebo i většina zaměstnanců. A v celkovém součtu je těch lidí spousta, protože malých firem/organizací bys musel napadnout mnohem víc než velkých korporací provozujících centralizované služby, abys dosáhl stejného výsledku.

Další věc je, že korporace má hodně co ztratit (např. se přijde na to, že jejich „daňové optimalizace“ jsou nelegální a je potřeba doplatit spoustu peněz, nebo nedostanou vládní zakázky, nebo se přijme nějaký zákon, který je poškodí…), zatímco malá firma toho tolik nemá (přinejhorším¹ zkrachují a nechají se někde zaměstnat a taky se nebudou mít špatně) a naopak tam je šance něco získat – zviditelnit se na odhalení vládních zločinů, získat tím jméno a pak (resp. před tím) třeba prchnout za hranice.

_{[1] taky by mohlo dojít na fyzickou likvidaci – ale pokud by např. v nějaké zemi začali ve velkém umírat provozovatelé hostingu nebo by např. velké procento z nich „mělo nehodu“ tak by si toho veřejnost všimla}

[kralyk z abclinuxu]

Pokud by mělo i plošný zásah (ne cílený na jeden SW), tak mi to na tom GitHubu nepřijde o nic méně nápadné, pokud by nešlo jen o pasivní sběr dat. Ale to je detail, hlavně ale moc nechápu, co tím chceš říct celkově.

Zkusim to jinak: Jestliže ti GitHub vadí, jaký bys navrhl postup pro docílení přelití té popularity z GitHubu na alternativní službu?

[xkucf03]

Ona by to hlavně neměla být alternativní služba. Měla by to být vhodná svobodná implementace (v tomto případě verzovací systém + něco navíc), kterou si vývojářské týmy budou moci běžně provozovat na svých serverech. A k tomu nějaká federace identit (ať už SAML IdP nebo OpenID nebo ta tvoje identita může vycházet z tvého veřejného klíče) a pak nějaký standardizovaný formát, ve kterém bys mohl publikovat svůj profil – např. jsem přemýšlel o XML formátu, ve kterém bys mohl zveřejnit informace o sobě, kontakty, svoje úspěchy (odkazy na tebou nahlášené chyby, implementované funkce, opravy…), reference a hodnocení ostatních (např. oblíbené programy, vývojáři, od kterých ses něco naučil, přínosní uživatelé…). Každý by tenhle soubor zveřejnil na svém serveru nebo na serveru své komunity a celé by se to nějak indexovalo, ideálně P2P vyhledávačem (YaCy?).

[kralyk z abclinuxu]

To vůbec neodpovídá na tu moji otázku ...

Krom toho, ty další služby, které zmiňuješ, jsou z hlediska používanosti v podstatě dost faily - Yacy, OpenID - přijde mi, že po nich neštěkne pes. Nerozumim, jak by to mělo pomoct.

[kralyk z abclinuxu]

Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut?

O tomhle to právě vůbec není. Zrovna dnes jsem řešil bug ve foss programu, který tady nejspíš všichni znají. Řešil jsem to během pracovního dne. Mám toho na práci víc než dost a musim řešit spoustu vlastních problémů, takže to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří čas.

A platí zde něco podobného jako v reakci na tu Frantovu stížnost na cenzuru Facebooku: Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím. Nehledě na to, že nikdo s tímto názorem zatím nepředložil důkaz, že bugreporty na self-hosted řešení jsou skutečně kvalitnější.

Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod.

Podobný problém má asi tak každý balíčkovací manažer. Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha. Nějak nevidim, co z toho. Na teoretické rovině s tebou souhlasim. A co dál? Pravděpodobně nic, nejspíše budeme oba spokojeně nadále GitHub... Nebo snad ne?

[ehm]

to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří čas

Kolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?

Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím.

Nekvalitní bugreport může přidělat hodně práce. Mám s tím z práce bohaté zkušenosti (převážně z reportů od UIčkářů). Nedávno jsem se rozhodl, že už to prostě nebudu řešit, dokud nebude přiložen detailní popis, podle kterého to půjde zduplikovat (nebo nebude výslovně uvedeno, že není známo, jak to zduplikovat, protože se to projevuje jen občas).

Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha.

Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.

[kralyk z abclinuxu]

Kolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?

Ten rozdíl efektivně pouze v URL nikdy nebude např. z toho důvodu, že na GitHubu mi přijdou notifikace o tom, že majitej repa mi odpověděl na můj bugreport (což se o hodinu později stalo). (Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.)

Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.

Zcela upřímně, kdyby ten projekt to měl nasazeno takhle nějak, tak jim tam dnes ten bugreport nejspíše nepošlu. Můžeš mě zažalovat nebo se pohoršovat nad tím, jak jsem hroznej a linej a kdesi cosi ... Ale to je tak celý.

Plus navíc ten projekt by musel vynakládat úsilí a finance na udržování toho setupu, a přitom GitHub poskytně lepší hodnotu za mnohem menší námahu a peníze. Opět máš možnost se pohoršovat dosytosti. A opět to na praktické stránce věci nezmění vůbec nic.

[xkucf03]

Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.

Osobně k tomu používám jednoúčelové e-mailové adresy na vlastní doméně – jedna adresa slouží ke komunikaci jen s jedním subjektem a kdyby došlo např. ke spamování, můžu ji okamžitě zaříznout. Dá se to i automatizovat – e-mailové aliasy se můžou vytvářet dynamicky resp. nemusí být ani nikde uložené – jen popsané algoritmem – např. doménaDruhéStrany + "." + hash(tajnýKód, doménaDruhéStrany) + "@x.moje-doména.example.com". A ten tajnýKód můžeš mít i v nějaké své aplikaci, takže pro přidání resp. vygenerování nového e-mailového aliasu ani nemusíš komunikovat se svým serverem (ten jen na základě algoritmu a sdíleného tajemství ověří, že daný alias je platný). Pokud by náhodou došlo k vyzrazení klíče, uděláš z dosud použitých aliasů (na které přišel nějaký e-mail) klasické uložené aliasy a nové začneš vydávat na základě nového klíče.

[kralyk z abclinuxu]

Ty máš asi ten overengineering opravdu hodně v oblibě Jak už jsem psal, ten projekt používá GitHub, takže nic takového jsem nemusel řešit. Jinak na tohle existuje mailinator (pozor: Hnusně centralizovaná proprietární služba).

[xkucf03]

Mailinator nebo podobné služby taky občas používám, ale to je jiný případ. To, co jsem popisoval, slouží ke spolehlivému doručování zpráv (třeba i za několik let, kdy už ta anonymní služba nemusí ani existovat), které nemají být veřejné (v rámci možností e-mailu). Cílem je, abych mohl sledovat, jak ostatní nakládají s mými osobními údaji a abych mohl snadno zablokovat případný spam.

[ehm]

Koukám, že je to s FOSS ještě horší než jsem si myslel. Ostatně, delší dobu si lámu hlavu, proč se vlastně vůbec obtěžovat svoje projekty dávat k dispozici ostatním.

[kralyk z abclinuxu]

Hele úplně příšerný to je, totálně hrozný. Dekadence, úpadek, liný lidi používající ten strašný GitHub, atd. Prostě fakt hrůza. Nemá to vůbec cenu, nejlepší se na foss úplně vykašlat.

(Dobrý, tak jsem se pohoršili, teď ještě splnit část 2: nezměnit nic praktického. Myslimže to taky nebude těžký, věřim, že to dáme.)

[ehm]

Mám několik menších projektů, které bych mohl zveřejnit. Je to pro mě extra práce, protože to jsou často bastly dělané na míru pro mě. Ve stávajícím stavu se mi to moc nechce zveřejňovat – cítil bych silné nutkání projít a začistit zdrojový kód (možná to i celé zrefactorovat), doplnit dokumentaci, pořádně to dootestovat a podobně.

Co z toho budu mít? Mohl bych si budovat jméno. Taky bych z toho mohl mít dobrý pocit. Co tam je dál? Teoreticky by mi někdo mohl s tím vývojem pomoci (alespoň třeba tou formou reportování bugů), ale to se u tak malých projektů, o kterých se bavíme, spíš nestane. Navíc ty sám připouštíš, že kdybys měl bug reportovat někam jinam než na GitHub, tak bys to vzdal. To je docela nepříjemné slyšet od člověka, kterého zrovna považuji za docela schopného a od něhož bych právě čekal opak.

Takže to mám v lokálním repozitáři a pokud už to někam pushuji, je to vlastní soukromý repozitář na mém serveru. Na jednu stranu mám chuť se o to podělit, ale na druhou stranu mi to přijde jako práce a zodpovědnost navíc, která není skoro ničím kompenzována. Nějaké částečné řešení se mi v hlavě rýsuje, ale to sem psát nechci.

[Want]

Pokud vím, tak u projektů na kterých má participovat víc lidí využívají pro tento účel Redmine.

[kralyk z abclinuxu]

Mám několik menších projektů, které bych mohl zveřejnit. Je to pro mě extra práce, protože to jsou často bastly dělané na míru pro mě. Ve stávajícím stavu se mi to moc nechce zveřejňovat – cítil bych silné nutkání projít a začistit zdrojový kód (možná to i celé zrefactorovat), doplnit dokumentaci, pořádně to dootestovat a podobně.

Taky mám všelijaké takové, spíš většinou šuplíkové napůl nedokončené projekty ... Asi ti k tomu nic moc moudrého neporadim, záleží případ od případu a jak moc se ti chce / nechce to zveřejňovat.

Ale v každém případě bych to nebral moc vážně. Když se podíváš, co jsou dnes lidi schopní zveřejnit za "projekty" - třeba JavaScriptové knihovny, které mají logo, baterii integračních testů a dokumentaci, to všechno jen kvůli třeba 50 řádkám reálného kódu* ... to pak zjistíš, že seš nejspíš úplně v pohodě i s nerefaktorovaným kódem.

*) Něldy ani to ne, viz třeba tady.

Navíc ty sám připouštíš, že kdybys měl bug reportovat někam jinam než na GitHub, tak bys to vzdal.

To zas ne. Tam šlo o ten kontext - byl jsem uprostřed pracovního dne, byl rozbitý build, potřeboval jsem rychle vyřešit problémy... Ve chvílích, kdy je víc klid a mam víc času jsem ochoten reportovat i jinam

[little-drunk-jesus]

Mne se na male nasazeni osvedcil gogs. Sice nema tolik features, ale je to snadno nasaditelne i updaty jsou vetsinou bezproblemove, umi bezet i nad SQLite, tzn pro domaci pouziti mi to prijde fajn.

[Josef Kufner]

Je jen škoda, že Gogs nemá integrované CI, jako má Gitlab.

[Helb]

Větve se mají jmenovat podle čísla issue, cokoliv jiného je anarchistický nesmysl

[lzap]

Kdepak, nějaké heslo a až zatím číslo issue/BZ. Mám 400 větví na hlavním projektu, čísla si nezapamatuju, ale např. subnet-workaround-26344 nebo rename-sha1-27645 již ano.

Napsal jsem dokonce tool na čištění větví, ovšem ho nepoužívám

https://github.com/lzap/git-xcleaner

[Josef Kufner]

Setkal jsem se spíš s opačným přístupem: 26344-subnet-workaround, 27645-rename-sha1.

[xkucf03]

To je takové systematičtější, ale je fakt, že pokud to má psát člověk z hlavy, tak si spíš vzpomene na to slovo a zbytek doplní mu bash completion.

[ehm]

Pokud vytvoříš jeden nic neříkající commit (jak jsi to sám nazval) a pak se nedokážeš v těch změnách vyznat, používáš git špatně. Smysl větve má být patrný z jejího názvu, podstata změn pak z commitů.

[Marián Kyral]

Navíc není problém ty parciální commity před mergem do hlavní větve sloučit do jednoho.

[Michal Kubeček]

Ne vždy je to ale žádoucí. Pokud jsou to jen "denní přírůstky", tak to smysl dává, ale pokud commity odrážejí nějaké logické členění, tak je lepší nechat je zvlášť. Často to dělám dokonce opačně: v první fázi vývoje nějaké featury má topic branch jen jeden "WiP" commit, který pak pomoci "git gui" rozdělím na jednotlivé commity (které lze pak ještě dodatečně upravovat pomocí "git rebase -i").

[kralyk z abclinuxu]

Osobně to mam obvykle tak, že do vývojové větvě dávám WIP commity jeden za druhým a pak to stlačím na zhruba 1/5 ~ 1/4 původního počtu.

Je ale pravda, že větší počet commitů se hůř rebasuje, může se stát, že v jednom commitu člověk řeší konflikty jen proto, aby v následujícím úplně zmizely ...

No nicméně zpětně rozdělovat jeden WIP commit na více dílčích a tím víceméně psát fiktivní historii mi nepřijde úplně smysluplný ...

[Michal Kubeček]

Je ale pravda, že větší počet commitů se hůř rebasuje, může se stát, že v jednom commitu člověk řeší konflikty jen proto, aby v následujícím úplně zmizely ...

To se sice stát může, ale až tak časté to není. Osobně radši dělám rebase série s jemnější granularitou, protože když na mne vypadne spousta konfliktů najednou, působí to na mne trochu depresivně a demotivačně. Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.

zpětně rozdělovat jeden WIP commit na více dílčích a tím víceméně psát fiktivní historii mi nepřijde úplně smysluplný

Nemyslel jsem tím fiktivní historii, ale rozdělení jedno monstercommitu na více logicky oddělených změn. Příklad viz třeba tady série ba3eb1a44b12..9fb1a27800d0 (normálně mívám commit message sdílnější, ale snažil jsem se přizpůsobit zvyklostem projektu). Sice by se to dalo sloučit do jednoho commitu "add IPv6 support", ale jsem přesvědčen, že takhle rozdělené je to mnohem přehlednější.

[dementni.lojzik]

Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.

no nevim, jestli jen vkusu. Me velke commity prijdou dost spatne z toho duvodu, ze delat review pull requestu, kde se meni kod treba ve 200 souborech (a uz jsem videl i horsi) je peklo a sance, ze se neco prehledne je podstatne vetsi, nez kdyz je to cleneno do mensich commitu. A i pokud je ten, kdo dela review je natolik schopny se koncentrovat, ze mu mu zadna chybu neunikne, tak tim urcite stravi o dost vic casu. Dalsi vec je, ze pokud se delaji backporty treba do nejake LTS vetve, tak se obcast stava, ze v ramci vyvoje nove funkcionality je upravena nejaka stavajici, kde se casem ukaze, ze tato jeji uprava je potreba backportovat. Udelat cherry-pick daneho commitu je bezpochyby mnohem jednodussi nez to dolovat z obrovskeho commitu. Takze IMHO clenit commity podle (pokud mozno malych) ucelenych logickych celku je vyhodnejsi jak kvuli mensi nachylnosti k chybam, tak celkove snadnejsi udrzovaletnosti kodu.

[SazeVaclav]

kde se meni kod treba ve 200 souborech

a ten, kdo to cele navrhoval, sef projektu a vsichni ti ostatni, co jsou zodpovedni za tu architekturu takoveho software - ti dostanou vypoved na hodinu a nebo smeji zustat celou vypovedni dobu?

[dementni.lojzik]

U open source projektu se obvykle nikdo nevyhazuje. Nicmene tito lide obvykle zustavaji mnoho let, nez je preplati nejaka firma, aby sli delat pro ne nebo nez jim prace na nejakem jinem projektu prijde zajimevejsi nez to, na cem poslednich par let delali.
Jinak to, ze se v ramci nejake zmeny meni kod ve 200 souborech neznamena, ze je project spatne navrzeny a stejne tak, i kdyz je (typicky z historickych duvodu) projekt spatne navrzeny, to nijak neimplikuje, ze hlavni vyvojar/architekt je neschopny retard, co by mel byt urychlene nahrazen nekym jinym.

[Kit]

Pokud nějaké individuum přejmenuje metodu v rozhraní a nechá v IDE přejmenovat všechny výskyty, tak to skutečně postihne i víc než 200 souborů naráz.

[Michal Kubeček]

Výraz "věc vkusu" jsem použil čistě v kontextu toho, co je praktičtější pro rebase lokální pracovní větve, kteřá je ještě "work in progress". Jakmile jde o hotovou verzi, která se má stát součástí historie ve sdíleném repozitáři, tam už podle mne megacommity nemají co dělat (s výjimkou nějakých tree-wide změn generovaných např. coccinelle - ale ani pak nemíchat nesouvisející změny).

[kralyk z abclinuxu]

Taky to na mě působí jako ne úplně správné použití gitu. Pokud ti tam vzniká větší množství větví s nedokončenou prací, u kterých už si ani podle šítku napamatuješ, co to bylo, tak bude asi něco špatně s workflow / způsobem vývoje té věci...

[Aleš Kapica]

To je zajímavé kolik z vás tady má křišťálovou kouli.

Já jsem nepsal že mám větší množství větví s nedokončenou prací, ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil. Což nesouvisí ani se jménem, ani s počtem větví.

V git adresáři cca 164 git repozitářů a zdaleka ne do všech se to týká. Většinu z nich mám jen k tomu abych se čas od času podíval na aktuální změny.

Pokud se týče správnosti použití gitu - nezdá se vám, že je to tak trošku moje věc, kdy, kde a nač ho nasazuji? Jen tak pro zajímavost - kolik z vás si hlídá jeho prostřednictvím změny konfigurace?

[kralyk z abclinuxu]

Ok, možná jsem to z toho špatně pochopil.

ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil

Jaký je tvůj usecase pro větvě, které nejsou master, ale existují dlouhodobě? Osobně když vytvořim větev, předpokládám u ní pokudmožno krátkou dobu trvání. V podstatě čím kratší, tím lépe. Případně si umím představit něco jako master + dev nebo master + stable nebo něco takového, některé projekty to tak mají.

Náhodné / ad-hoc větve, které ale existují dlouhodobě, mi čistě osobně a subjektivně nepřijdou jako dobrý nápad. Je to jenom moje 0.2$, můžeš samozřejmě neoushlasit a dělat si s gitem co chceš...

Jen tak pro zajímavost - kolik z vás si hlídá jeho prostřednictvím změny konfigurace?

V gitu mývám všechno možné...

[Michal Kubeček]

Vždy se najdou výjimky. Já mám třeba v gitu spoustu větví, které přidávají nějaký specifický tracing určený pro konkrétní bug. Ty se hodí zachovat, protože později můžu chtít použít podobný nebo dokonce stejný patch a nemusím ho tak psát znovu.

No a potom existují hodně specifické repozitáře jako např. tehnle, kde se vlastně všechno zajímavé odehrává mimo master branch.

[Aleš Kapica]

Tak s větvemi pracuji trochu více především u wiki. Je to dané tím, že vycházejí z verzí a jsou na ně navázaná některá z rozšíření. Pro takový případ je třeba mít situaci ošetřenou tak, abych se mohl rychle vrátit k funkčnímu řešení.

Ve většině případů se obejdu i bez těch popisů. Ovšem teď jsem začal dělat na věci, kterou autor sice spravuje v gitu ale moc nepoužívá větve. Navíc se jeho představa o celkové koncepci poněkud liší od té mojí. Takže něco z toho co jsem mu poslal sice využil, ale některé základní komponenty potřebuji napsat úplně jinak než jak je má napsané teď. Mám tak svoji vývojovou větev, jeho hlavní větev. Větev ve které mám sloučené změny. A větev ze které mohu generovat patch, co pak může on aplikovat na svoji větev, aniž by si tím něco rozbil.

[Josef Kufner]

Já jsem nepsal že mám větší množství větví s nedokončenou prací, ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil. Což nesouvisí ani se jménem, ani s počtem větví.

A co ti brání takovou větev prostě zahodit? Zjevně už není potřeba. (Leda by na ni vedl odkaz z nějakého úkolovníčku, ale to by začínala číslem issue.)

[trekker.dk]

Přesně, pokud si už nepamatuju, k čemu je to dobré, nejspíš už to k ničemu není

[ehm]

Samozřejmě můžeš používat sekyru na zatloukání hřebíků, ale nemůžeš se divit, že pak budeš potřebovat ochrané pouzdro na čepel, aby sis při nápřahu nerozsekl čelo; a stejně to nebude tak dobré jako kladivo.

[Aleš Kapica]

Kdo se při zatloukání hřebíků sekyrou tne do čela, je podle mě lopata, které nepatří do ruky ani kladivo.

[ehm]

A podle mě jsi lopata ty, když se nedokážeš orientovat ve změnách, které máš ve verzovacím systému, a obcházíš to nějakým dodatečným popiskem k větvi. A dobrovolně tou lopatou jsi dál, protože ti ješitnost a arogance nedovolí připustit, že profesionální programátoři, kteří ti tu zkouší poradit, možná mají pravdu.

[trekker.dk]

Nicméně pravda je, že pokud se někdo sekne do čela, když sekerou zatlouká hřebíky a nemá na ní přitom ochranné pouzdro, tak mu to patří.

[Want]

Evidentně jsi nepochopil, že tenhle blogpost není dotaz v poradně, ale omáčka k informaci o tom, za jakých okolností se může hodit dodatečný popis u lokální větve git repozitáře.

[ehm]

Ale ten důvod není validní.

[Aleš Kapica]

Jaký "důvod"?

[Aleš Kapica]

Považuji za totální úlet řešit validitu, neboli platnost "důvodu", který vyvozuješ na základě popsané skutečnosti (faktu). Jednak těch příčin (důvodů) je celá řada, a druhak ti mohou být zcela ukradené, stejně jako ostatním diskutujícím, protože jsou moje.

Pokud jsi cítil v této diskuzi nutkání někoho poučit, fajn. Někdo si toho možná všimne a třeba mu to bude i ku prospěchu. Ovšem ti co znají své limity nad tím akorát s lehkým úsměvem pokývou hlavou. Protože každý používá nástroje co má k dispozici jak nejlépe umí a ne tak jak si představuje někdo jiný.

[Michal Kubeček]

Najdou se ovšem i takoví, kteří jsou ochotni nad radami druhých zamyslet a občas některé třeba i do svého workflow přejmout.

[Aleš Kapica]

Někdo si toho možná všimne a třeba mu to bude i ku prospěchu.

Ovšem to asi nebude případ těch, co nevšimli ani toho, že jsem se o nich zmínil.

Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí.

Spolupráce na projektu je podmíněna tím, že se v prvé řadě stanoví jak takové workflow bude vypadat, důsledně se pak dodržuje a nově příchozí ho pak buď akceptuje (a k projektu se přidá) nebo si udělá fork a nastaví si vlastní workflow pravidla.

A právě v situaci, kdy chci zkombinovat věci které mají různá workflow do jednoho projektu, se může hodit onen lokální popis.

Jinak ta diskuze je téměř od samého počátku mimo mísu. Relevantní byla tak maximálně poznámka, že k přepnutí větve s rozdělanou prací lze použít příkaz stash. Následující dohady, jestli používat gihub, nebo něco jiného. Nebo jak si pojmenovávat větve. Jsou už na úrovni hospodského dohadování. A tomu také odpovídají i moje reakce v tomto vlákně.

[trekker.dk]

Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí.

Podle sebe soudím tebe...

[Aleš Kapica]

V takovém případě mi tedy musíš dát za pravdu.

[ehm]

Faktem je, že jsi měl problém, nikoliv, že bylo vhodné ten problém řešit dodatečným popiskem k větvi.

[Aleš Kapica]

Sorry, ale ta věta je poněkud zmatená. Měl jsem několik větví, vytvořených z různých stádií kódu, který psal někdo jiný, v každé fungovalo něco a tak mě napadlo, že určitě existuje možnost si ty větve popsat podrobněji. A protože mi to přišlo jako docela zajímavá a užitečná funkcionalita o které se moc nemluví, sepsal jsem tenhle blogpost. Takže pokud jsem měl podle vás problém, tak podobných řeším denně tucty, aniž bych měl o tom potřebu psát.

[ehm]

Nikdo ti nevyčítá, že jsi napsal blogpost. Zajímavá věc to je, užitečné to může být taky. Jen se to mně a pár dalším lidem nezdá jako nejvhodnější řešení toho problému, který jsi tam naznačil. To je celé. Nemá smysl do každého komentáře cpát slovní vatu jen proto, aby se náhodou někdo nerozhodl nechat se tím urazit („Neznám celý kontext, ale podle toho, jak si to v blogu formuloval, to vypadá, že git nepoužíváš úplně správně (ve smyslu toho, jak byl navržen, a jak je zpravidla používán nejefektivněji). Neber to prosím zle, můžeš jej samozřejmě používat jakkoliv uznáš za vhodné (a sám také, bohužel, dělám spoustu věcí neefektivně), ale možná by bylo lepší zkusit ... blá blá blá“). To je patetické, hloupé, zbytečné a bezpředmětné.