Asi si přímo nestěžuje na Link samotný, jako na to, že tam lidi (nebo spíš automatizované nástroje) cpou link na stránku, kde je souhrn toho, co stejně vidí ve svém prostředí - přitom přítomnost Link by měla odkazovat na další informace. Pak se smysl značky ztrácí, protože na to nikdo klikat nebude, nepozná co je důležité a co ne.
Úplně jsem bez další analýzy nepochopil,o co přesně jde, proto to píšu.
Vzhledem k tomu, že má Linus právo takový patch odmítnout, a také to udělal, žádné plané křičení do větru to není. A požadavek na nějakou minimální kvalitu patchů je zcela legitimní – přičemž k tomu patří i to, že z informací dostupných v patchi (včetně odkazů) musí být zřejmé, co a proč patch dělá.
Ale možná jste tím výkřikem myslel sám sebe…
Ty patche co jsou strojove - a vicemene formatovaci, pro dodrzeni konvenci, by meli byt aplikovany pred vydanim naraz. Nebo udelat cleanup minor verzi, kdy se uklidi ruznej bordel.
A pak to muze mit format - co patch, to jedno formatovaci pravidlo. A ne ze se to bude posilat po drobkach..
Jinak formatovaci patche jsou jedna ze slabin GITu - kdyz vam tam ujede treba tab, nebo mezery na konci radku a snazite se to napravit.. tak to zasvini hezkou historii i git blame.. holt nekdy by bylo potreba zasahnout i do starsich commitu a nechat je updatnout (verzovat, revizovat - dalsim clovekem).
Tak pro prijeti do kernelu by mel commit uspesne projit pres checkpatch.pl, rada maintaineru to (automaticky) kontroluje. Ten formatovaci chyby odchyti (bohuzel ne treba u DTS a obecne non-C kodu).
Zpetne commit opravit muzes pres rebase, ale samozrejme nesmi byt jeste sdilen, aby v tom ostatni nemeli gulas. Jak bys to chtel delat, kdyz kazda zmena vygeneruje novy hash commitu?
Jsem tak nejak mel za to ze kazdy pricetny programator, co se hodla pochlubit svym dilem, pouziva nejaky lint co mezery na konci radku a taby navic srovna.
Git nemuze vedet jestli zrovna pracuje s jazykem kde mezera na zacatku je extremne dulezita (python) nebo naprosto nedulezita (latex).
A kdyz vyvojar udela blby commit, a pak si jeste opravi format dalsim commitem, tak jsem mel za to ze na to tu je nastroj squash, ne?
Squash se dá udělat, dokud ty commity máte jen lokálně. Jakmile je ten první pushnutý do veřejně přístupného repozitáře, je to krajně nežádoucí.
Ještě jako programátorské nemluvně mě proškolil jeden kolega, který vytvořil commit s nějakou změnou, napsal shrnutí do první řádky, a následně tam uvedl celkem rozsáhlý popis, kde vysvětloval co tam udělal, proč to tam udělal, proč to neudělal jinak. Dost mě to inspirovalo.
Většina věcí patří do kódu. Ale v tom commitu můžou a možná by měli být věci, které celou tu změnu nějak zastřešují a i obhajují.
Jak říká Linus: být užitečný.
Naozaj? A nie je lepsie link do nejake nastroja povedzme ze Issue alebo Project tracking kde je historia, prispevky od roznych ludi, vysledky testov z jednotlivych prostredi, rozne dalsie dokumenty, ...?!? V zdrojaku alebo commite potom staci taky klasicky LK-000342.
Ne, to by rozhodně nebyl dobrý nápad. Link: může odkazovat na dodatečné informace a třeba i někam do bugzilly nebo jiného trackeru, ale to podstatné, tedy co se vlastně mění a jak a hlavně proč, to musí být obsaženo už v commit message. Často musím procházet historii konkrétního souboru pomocí něčeho jako git log -p -U10 -- ... a ten hledaný commit je dost náročné najít, i když jsou commit message napsané pořádně. Kdyby polovina jen odkazovala někam na různé weby, tak se z toho zblázním. Navíc jednou ze zásadních výhod gitu je, že se spousta práce dá udělat offline, o to bychom takovým přístupem z velké části přišli, kdybychom bez připojení ani pořádně nemohli zjistit, co ten commit vlastně dělá a proč.
> spousta práce dá udělat offline
Ano, mozete aj tak nozikom vyrezavat do drevka zarezy
> hledaný commit je dost náročné najít
Ale tie nastroje obvykle ponukaju full text search nad vsetkym vratane toho DIFF-u takze pokial aspon 'tusite' co hladate tak ziadny git log nepotrebujete.
Ano, mozete aj tak nozikom vyrezavat do drevka zarezy
Tak to se omlouvám za nedorozumění, naivně jsem si myslel, že jde o vážnou diskusi o práci vývojáře.
Ale tie nastroje obvykle ponukaju full text search nad vsetkym vratane toho DIFF-u takze pokial aspon 'tusite' co hladate tak ziadny git log nepotrebujete.
O jakých nástrojích je tu řeč? Mám historii změn v určité funkci, která se změnila mnohokrát a není na první pohled jasné, kde konkrétně došlo ke změně, která je pro mne relevantní. Polovna commitů, které na ten kód sahaly, nebude mít Link: tag vůbec a ta druhá polovina bude odkazovat na několik různých trackerů a dalších webů. Každý vypadá jinak, je jinak organizovaný, provozovaný někým jiným a slouží úplně jinému účelu. Kvalitní commit message mi pomohou najít, který je ten pro mne zajímavý (klidně jich může být i víc), a pochopit, proč se to změnilo a proč zrovna takhle. Když tam místo toho budou jen odkazy na hromadu různých webů, celý proces bude řádově méně efektivní.
Když už se potřebuju detailně zaměřit na nějaký commit, může mi Link: poskytnout odkaz na další zdroje, kde se můžu dozvědět víc. Ale to podstatné musí být obsaženo už v commit message, nelze to schovávat za link a myslet si, že to tak stačí. Jistě, jsou projekty, kde vám to projde. (Jsou i porjekty, kde vám projde i "commit message" ve znění some changes
. Ale linuxové jádro - tedy aspoň jeho rozumně udržované části - mezi ně naštěstí nepatří.
Muze poskytnout... za predpokladu, ze ten cil jeste bezi. Ale historie pamatuje hromadu pripadu, kdy zdroj bud zaniknul zcela... a nebo "jenom" zmenil strukturu tak uzasne, ze odkazy prestanou fungovat :)
A mimo jiné i proto je třeba, aby popis commitu obsahoval užitečné informace osvětlující obsah a pozadí vzniku daných změn.
Muze poskytnout... za predpokladu, ze ten cil jeste bezi.
Pravda, persistence těch odkazovaných zdrojů je z dlouhodobého hlediska mnohem větší problém než to, o čem jsem psal.
Jedná se hlavně o nepochopení k čemu slouží které nástroje.
Git je verzovací nástroj. Slouží k tomu, aby se evidovali změny a featury, a případně se s nimi dalo manipulovat. Tudíž z logiky věci, do commit message píšu, co a proč tato změna.
V kódu a v komentářích v kódu píšu, co co dělá, k čemu to slouží, jak se to používá - reflektuje to aktuální stav.
Trackovací nástroje slouží k plánování a diskusi změn.
Úplně tam nepozoruji žádný průnik. Proto se domnívám, že původní představa "A nie je lepsie link do nejake nastroja povedzme ze Issue alebo Project tracking" je zcela chybná.
Nicméně i u velmi nelevných profesionálů je krásně vidět, jak podobné naivní představy končí... https://community.f5.com/discussions/technicalforum/broken-links-on-devcentral/217921 (BTW už 4 roky starý příspěvek, nemalý problém je do teď když člověk něco specifického hledá...)
Ne, linkovat na externí zdroje opravdu není ve střednědobém horizontu dobrý nápad, a ani nejdokonalejší AI powered full text search toho na broken linku moc nenajde...
U jednoho klienta během posledních let změnili asi 4x trackovací systém. Některé věci se migrovaly, některé věci nepřežily. Ne, doopravdy není dobrý nápad mít v message pouze link.
Technická podpora má svůj trackovací systém, vývoj různé podle projektů a testeři opět jiný. Navzájem si do karet nevidí.
Low level moduly a jejich repo jsou navíc sdílené mezi různými projekty.
Link ukazující někam, kde mám "access denied" mi moc nepomůže.
Link stačí? Člověče, neblaznete, nejste ai, abyste mohl beztrestně halucinovat.
Dělal jste vůbec někdy v životě na kódu alespoň čtvrt století starém?
Jestli vůbec tušíte, která bije...