rgb to gray (parancssorban hogyan) [megoldva]

Segédprogramok

Sziasztok.

Van egy könyvtáram, tele irgalmatlan képekkel. RGB mind, főleg jpeg kódolással, de van png is.

Mindet gray-jé szeretném tenni, vagyis szürkeárnyalatossá. (Alábbi táblázatban látszik, melyik a "color".)

Az encoder, vagyis a jpeg megmaradna. Létezik erre BASH-ban akármi? NEm szeretnék egerészni GUI-s programokban, mert kihullik a hajam.

 

page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
   3     0 image     264   409  rgb     3   8  jpeg   no       219  0   189   189 11.3K 3.6%
  10     1 image     640   480  rgb     3   8  jpeg   no       277  0   302   302 40.7K 4.5%
  13     2 image    1402   942  rgb     3   8  jpeg   no       309  0   850   850 95.1K 2.5%
  24     3 image     656   264  rgb     3   8  jpeg   no       367  0   254   254 22.6K 4.5%
  26     4 image     512   117  rgb     3   8  jpeg   no       387  0   169   169 13.5K 7.7%

 

 

 

%%%%%%%%%%
Megoldódott: https://hup.hu/comment/2969239#comment-2969239
Köszi mindenkinek! :-)

  • 1023 megtekintés

Köszi, írom is a scriptet, ami reggelre megcsinál mindent nekem.

Létezik ugyan a convert az ImageMagick-on belül, mégis gimpeltem, kritáztam, azok meg alattomosan meRGB-zték nekem a szürkeárnyalatost...
Vagy a harmadik lehetőség: a Gimp jpeg to eps konvertere szórakozik.
Negyedik lehetőség mindenképp fennáll: hülye vagyok. :)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

( blr v | 2023. 09. 21., cs – 20:56 )

Szerkesztve: 2023. 09. 21., cs – 21:02

A jpegtran lesz a barátod, újratömörítés nélkül tudsz vele grayscale-be „konvertálni”.

(A PNG-kre meg marad a IM.)

> ez sajnos windowsos.

tuti?  https://linux.die.net/man/1/jpegtran

ha jol ertem ennek a resze, ez pedig van unixra is:  https://www.ijg.org/

vagy ez: https://github.com/cloudflare/jpegtran

de nem lehet tul nehez megirni linuxra se. csak a YUV-bol az U/V (chroma) layereket el kell dobni, es a Y (luma) marad egyedul. a headerben csokkenteni a channelek szamat es kesz is.  kb kizart hogy nem irta mar meg valaki, de lehet ha nagyon unatkozok osszedobom ez alapjan:

https://github.com/gereoffy/drutils/blob/main/testjpeg.py

köszi, megnézem

---

...azaz nézném, de kijelentette az apt, hogy:

 

  • "egy lehetetlen állapotot kért, vagy ha az unstable disztribúciót használja, akkor néhány igényelt csomag még nem készült el vagy ki lett mozdítva az Incoming-ból."

Ez a kedvenc üzeneteim egyike.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

( PeterX | 2023. 09. 22., p – 10:49 )

for file in *.jpg;do convert -colorspace Gray $file $file; done

Megcsináltam, működik.

Vegyesen vannak jpg és png képek, utóbbinál alfacsatorna. Vagyis az összes PNG kép egy része átlátszó hátterű.

Ezeket a convert program oly módon alakítja eps-sé, hogy pont az átlátszó hátteret feketíti.

Most ezzel küzdök, izgalmas. HA mást nem találok, akkor csak a png képeket inkscape alól exportálom gray-ként.

 

--------------

a megoldás plusz két kapcsoló a convert-hez:

-background White -alpha Background

vagyis a teljes konverzió így történik:

 

#!/bin/bash

for file in *.jpg;do convert -colorspace Gray -background White -alpha Background$file $file; done

for file in *.png;do convert -colorspace Gray -background White -alpha Background$file $file; done

exit 0

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

for file in *.jpg;do convert -colorspace Gray -background White -alpha Background $file $file; done

for file in *.png;do convert -colorspace Gray -background White -alpha Background $file $file; done

# hiba javítva, mindkét $file előtt hiányzott egy space.

Amúgy semmilyen fájlnevemben nincs space, sem ékezet. Az egy windows-csökevény. Egy rossz szokás, hogy a programozó önmagát szívassa plusz kóddal.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

for file in *.jpg *.png;do convert -colorspace Gray -background White -alpha Background "$file" "$file"; done

 

Igen, a hiba most már valóban javítva. Mondjuk az a hiba változatlanul fennáll, hogy ha valamelyik "kiterjesztésű" fájl nincs, akkor ott a *.akármi megmarad a for listájában, így egy convert hívás le fog futni *.jpg vagy *.png paraméterekkel is.

user@hostname:~/x $ for i in * ; do printf '%s\n' $i ; done
alma
szilva
narancs
user@hostname:~/x $ for i in * ; do printf '%s\n' "$i" ; done
alma szilva
narancs
user@hostname:~/x $ 
 

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( bzs v | 2023. 09. 22., p – 16:58 )

Amúgy előfordulhat, hogy míg az inkscape eps-exportja megtartja a gray-t, addig a Gimp átlövi rgb-be, csak azért, mert az eleve csak abban hajlandó tevékenykedni?

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Amúgy előfordulhat, hogy míg az inkscape eps-exportja megtartja a gray-t, addig a Gimp átlövi rgb-be, csak azért, mert az eleve csak abban hajlandó tevékenykedni?

Talált, süllyedt! jpeg-load.c#L202

case 4:
  if (cinfo.out_color_space == JCS_CMYK)
    {
      image_type = GIMP_RGB;
      layer_type = GIMP_RGB_IMAGE;
      break;
    }

E szerint a "switch" szerint bármilyen jpeg színprofil végül mindenképp vagy GIMP_GRAY_IMAGE vagy GIMP_RGB_IMAGE layer-t eredményez betöltéskor, harmadik opció nincs.

Köszi!

Azért reménykedek, hogy a brutálisra növekedett Gimpet megokosítják CMYK színkezeléssel végre. Szégyen, hogy az eleve művészek által tervezett Krita is kenterbe veri már bizonyos téren.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Ne is mondd! Idestova 20 éve használok GIMP-et, de egyre nagyobb és határozottan egyre szarabb lesz! Folyamatosan azzal szembesülök, hogy valami korábban tök jól működött benne, de már elmúlt.

/rant on

Az mindennapos, hogy folyton elcseszik nekem a begyakorolt workflow-mat, mindig megakadok egy-egy frissítés után (pl a nagyítás nem működik többé, csak ha a select tool-on állsz, vagy ha move tool-t választod, nem mindig tudod mozgatni a kijelölt dolgot a kurzorbillentyűkkel, mert nem biztos, hogy a kép az aktív, ahhoz oda kéne kattintani, na de ha odakattintasz, hogy aktív legyen, akkor meg eltűnik a kijelelőlés...)

De ezek csak apróságok. Az első komoly érvágás az volt, hogy megszűntették a plugin támogatást a honlapon (most úgy kell levadászni őket innen-onnan, aztán reménykedni, hogy a verziók kompatíbilisek), aztán lecserélték a plugin motort is és sokkal szarabb minőségben újraírták (nézd csak meg, pl "Filters" > "Light and Shadow" alatt a régi "Drop Shadow (legacy)..." és az új "Drop Shadow" közti különbséget. A régit ha bezárod meg újranyitod, megjegyzi a beállításaidat. Az új képtelen erre a hihetetlen fejlesztési igényű bravúrra, mindig újra és újra be kell állítani az összes nyamvadt paramétert, ami enyhén szólva is kurva idegesítő, és ráadásul nem is új layer-re generálja az árnyékot, nehogy értelmesen használhasd az eredményét... A régihez képest egy fos).

A legújabb GIMP nyűg például az, hogy a legutóbbi frissítés óta nem tudok PNG alpha-t menteni. Eddig tudtam. A fájl létrejön, de bizonyos színek elmásznak (egy bizonyos pirosból pl szürke lesz), és ott, ahol teljesen átlátszónak kéne lennie képnek, random zaj van... Az stdout meg persze tele van GEGL buffer hibaüzenetekkel, de ezeket mindig is fosta magából, tök mindegy, milyen gépen és milyen GPU driverrel használtam, így nehéz megmondani, van-e közük hozzá. Az egyetlen megoldás, hogy ImageMagick-el konvertálom a lementett true color XCF-et palettás PNG-vé, ami azért hát de bammeg...

A rendes palettás alphát sem képesek megoldani már mióta (alpha csatorna elveszik ha indexed módra kapcsolsz, csak vág: vagy van vagy nincs között oszt csók, átmenet nuku). Most már ott tartok, hogy palettás képekre nem is használok inkább GIMP-et, hanem grafx2 (ennek bűn rossz a felülete, de ez legalább helyesen működik és jól menti a palettás PNG-t).

/rant off

Együttérzek, teljesen igazad van. Ezért is preferálom a CLI, TUI megoldásokat, azok állandóak, nem bolygatják őket, terminálban, tty/SSH konzolban is mindig működnek, elmennek, azonnal betöltenek egy gyenge, régi gépen is, könnyen portolhatók bármilyen unixos és unixlike rendszerre. Nem húzzák ki a talajt a user alól mindenféle UI átszerverzéssel, megváltozott default beállításokkal. Jó, az ImageMagick convert (meg az ffmpeg, sox, stb.) felparaméterezése kicsit bonyolult, agyrém, de egyszer kell megcsinálni, utána el tudod menteni scriptként, vagy shell aliasként, és bármely mappából indítva find / fd paranccsal megkeresi az aktuális mappában a képeket, for ciklussal átmenve rajtuk átkonvertálja őket gray scale-re, úgy, hogy nem kell többé neked parancssori paramétereket gépelgetni, azokra emlékezni, és tuti fog 20 év múlva is működni, nem hányják el benne a beállításokat, funkciókat.

Ugyanez a helyzet a nagy asztali környezetekkel, azokat is mindig átalakítják, átvariálják, lebutítják, ezzel szemben az egyszerű ablakkezelők egy darab jól megírt config fájl alapján örökké működnek, nem fognak kiterelni a jól megszokott workflow-ból, meg felidegesíteni újrareformált baromságokkal, amelyeket valami öltönyös-nyakkendős, nagy céges, trenddiktáló divatidióta (Gnome, Red Hat / IBM vagy Oracle berkeiben) épp kitalált kínjában, csak hogy ne maradjon olyan, mint a régi, meg valami indokkal felvehesse a fizetését.

Legújabb Windows és MacOS verziókban is szokás állandóan mindent átalakítani, meg frusztrálni a usereket, hogy újat kell megszokniuk, tanulniuk. Photoshop sem különb ám, nehogy azt hidd, mert ott is állandóan átvariálnak, meg kivesznek, extra fizetőssé tesznek benne feature-öket (Pantone-színek pl.), és ott még azt sincs, hogy maradsz régi verzión, mivel szerver/felhő alapú, ezért rád tolják az új verziót, nem tudsz ellen mit tenni, ki vagy szolgáltatva. Ezzel hálálják meg, hogy fizeted nekik a drága havi bérleti díjat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezért is preferálom a CLI, TUI megoldásokat, azok állandóak, nem bolygatják őket, terminálban, tty/SSH konzolban is mindig működnek, elmennek, azonnal betöltenek egy gyenge, régi gépen is, könnyen portolhatók bármilyen unixos és unixlike rendszerre.

Hát sajnos azért ott is előfordul, hogy átvariálják a kapcsolókat. De jóval ritkábban, tény. Egyébként én is ezért preferálom a CLI-t, sokkal hatékonyabban lehet dolgozni vele, mint bármilyen GUI-s felületen, és sokkal nagyobb eséllyel marad működőképes.

Jó, az ImageMagick convert (meg az ffmpeg, sox, stb.) felparaméterezése kicsit bonyolult, agyrém

Á, az hagyján. A CLI-k csimborasszója a git. Még a legrutinosabb, git-et rendszeresen, napi szinten használó emberkéknek is kell gugliznia néha-néha, mert egyszerűen képtelenség megjegyezni a kapcsolóit, a manualja meg megint akkora és még szét is van darabolva, hogy lehetetlen bármit is megtalálni benne (technikailag egy zseniális megoldás, ilyen szempontból imádom, na de a parancssori kapcsolói, könyörgöm... reset az igazából deselect, checkout HEAD^ meg az undo?)

És igen, az ImageMagick sem sokkal egyszerűbb, nekem egyszer két napom ráment, hogy keressek egy kapcsolót, végül feladtam, és megírtam inkább magam egy óra alatt az egészet (ld. pngpal). A feladat az volt, hogy egy csomó képet kell konvertálni pontosan ugyanarra a palettára (ugyanannak a színnek minden képen ugyanazzal az indexszel kell szerepelnie). GIMP-nél elveszik az alpha csatorna ugyebár, és mint kiderült, az ImageMagicknek meg soha nem is volt ilyen kapcsolója (más is beszopta, hogy a remap színelőfordulás szerint átrendezi a palettát).

mivel szerver/felhő alapú

Na ez meg a másik, amit sosem fogok megérteni. Nincs semmi gond azzal, ha egy programnak van hálózatos funkciója is, na de amikor a net nélkül meg se nyekken semmi, azt kurva nagy gáz. Egyszer legyen csak az ISP-nél áramszünet, és totál leáll az egész cég (hisz még a rajzolóprogram is cloud-os). Egyszerűen nem értem, hogy lehet képes bárki is egy ilyen nyilvánvaló single point of failure-re alapozni a teljes működését, ráadásul a sok idióta még tapsol is hozzá, hogy mennyire cutting-edge a cége... és akkor a biztonsági kockázatokról még nem is beszéltünk, teszem azt az a feladat, hogy egy céges titkokat tartalmazó képet kell átméretezned egy doksiba. Szerinted hány embernek esik le, hogy a cloud-os proggival máris kiszivárgott a céges titok és megy az MI betanítására, ahonnan aztán bárki lekérheti egy prompttal? Nem légbőlkapott példa, konkrétan megtörtént, és most már nemcsak a Photoshop, de még a legratyibb MS Paint is felhős meg MI-s lett, szóval...

Igen, az igaz, hogy néha átvariálnak, de azért nem annyira jellemző, mint a GUI-soknál. Nyilván nem lenne szabad nekik egyiknél se variálni, de azért terminálos megoldásoknál jobban meg van kötve a kezük.

A git-tel semmi baj nincs, igen, a logikája és parancsai kicsit logikátlanok, de simán meg lehet szokni, meg azt a pár funkciót belőle, amit az ember használ, arra aliast, vagy hasonlót csinálni. A legtöbb ember csak egyszerű git clone, git pull, git push, stb. szintű dolgokat használ.

Az ImageMagick színpalettára nem tudok mit mondani, ez még nekem sose kellett, hogy a képek palettáját, színindexelést azonossá tegyem.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( kroozo v | 2023. 09. 26., k – 08:38 )

> A git-tel semmi baj nincs, igen, a logikája és parancsai kicsit logikátlanok,

De, van rohadtul nem megy neki az easy things easy. A logikájával semmi baj nincs, az adatmodell elég jó, a modellel dolgozni viszont elég szar, és ha valóban dolgozol vele, akkor nem lesz elég a push pull commit.

De, van rohadtul nem megy neki az easy things easy. A logikájával semmi baj nincs, az adatmodell elég jó, a modellel dolgozni viszont elég szar, és ha valóban dolgozol vele, akkor nem lesz elég a push pull commit.

Igen, én is effelé hajlok. Az adatmodellje piszkosul jó, messze kenterbe ver minden mást, de óriási hiba volt azt egy-az-egyben kivezetni a CLI kapcsolókra (mármint csakis kizárólag ilyen kapcsolókat adni). Mindenképp kellettek volna olyan CLI kapcsolók, amik a megszokott sémát követik, a felhasználási oldalról megközelítve a dolgot, tök függetlenül attól, hogy mi és hogyan történik belül a motorban. Szvsz.

És azzal is egyetértek, hogy normál használat mellett is kevés a push pull, és hogy néha még a legegyszerűbb dolgok sem easy-k.

Itt egy konkrét példa (szerintem eléggé életszerű), amit képtelen volt a git megoldani: adott egy remote repó, amit klónoztam lokálba. Módosítottam egy fájlt, majd a gyerek játszani akart a gépen. Ezért átmentem az ócska laptomomra, oda is leklónoztam, elvégeztem pontosan ugyanazt a módosítást, mint az első gépen, és pusholtam a remote-ba. A gyerek befejezte a játékot, visszamentem a gépemre, de képtelenség volt onnantól a git-et használni. A git képtelen volt kezelni azt, hogy amit letöltene, meg ami már a diszken van az tök ugyanaz.

Próbáltam visszacsinálni a módosítást, meg mindenféle kapcsolókat kerestem neten, de hiába, nincs megoldás (ha nem commitoltam volna a módosítást lokálba, akkor simán ment volna, de sajnos commitoltam, és innentől a git log elágazott, hiába voltak a fájlok bitre ugyanazok a két repóban, és ezen a checkout sem segít, a merge meg a rebase meg egyszerűen nem volt hajlandó lefutni, mivel a két hash megegyezett, üres volt a diff). Egy darabig még szívtam vele, de aztán inkább repó letöröl, újraklónoz lett ennek is vége (mert az sokkal, de sokkal kevesebb időmet vette igénybe, mintha továbbra is a git kedvére akartam volna tenni).

en mar attol kivagyok, ha githubon weben szerkesztem a readme-t, localba meg mondjuk a hello.c-t. aztan mikor commitelni akarok nem engedi mert vannak modositasok remote (a readme). ok, akkor elobb git pull. hat akkor mar azt se lehet...  azert lekezelhetne magatol ha 2 kulonbozo fileon van modositas, nem kell semmit mergelni

Ezt nem tudtam reprodukálni, szemrebbenés nélkül megcsinálta a rebase-t:

$ git pull
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0
Unpacking objects: 100% (3/3), 269 bytes | 269.00 KiB/s, done.
From github.com:aaaaaa/bbbbbbbb
   72557fa..45ddf2a  Gittest    -> origin/Gittest
warning: skipped previously applied commit e6c8135
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks false"
Successfully rebased and updated refs/heads/Gittest.


$ git diff 72557fa..45ddf2a
diff --git a/gittest.txt b/gittest.txt
index 43a29be..96c4e93 100644
--- a/gittest.txt
+++ b/gittest.txt
@@ -11,3 +11,4 @@ drwxr-xr-x 31 fisher fisher 4096 Oct  6 00:25 opt


 Added
+Added 2

$ git --version
git version 2.39.2

De lehet hogy félreértettem valamit.

Végül is az nem rossz megoldás. Még egy nagyobb, több gigás adatméretű tárolónál is simán megérheti, hogy utána a szopást elkerüld. Nyilván a git-nek megvannak a maga szakmai mélységei, de azt mint írtam, nem mindenki használja úgyse. Én magam is csak normi szinten vagyok belőle, és az elég is nekem, bár tény, hogy illene alaposabban megtanulni, mert sok hasznos dologra jó, akkor is, ha az ember nem programozó, hanem esetleg csak szöveges doksikat, konfigáfájlokat, backupokat verziókövet vele.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ah, erről jól lemaradtam bocsánat. Mese következik, elnézést :) Igen, ez egy elég jó példa, mert viszonylag triviális, de könnyű beszopni, leginkább azért, mert nem érted az adatmodellt, vagy legalábbis nem hasznáod/gondolkodsz abban, de nem segít az sem, hogy a parancsok nevezéktanja csak kérdéses összefüggésben áll ezzel a modellel. Én mindig azt szoktam mondani a kiscserkészeknek, hogy mikor a gittel dolgoznak, akkor nem fileokban gondolkozunk (mint itt imho te is tetted), hanem commitokban (amik changesetek), az ezek közti összefüggésekben, és értsük meg, hogy branch simán csak egy pointer egy commitra. (Meg azért is jó példa, mert világosan mutatja, hogy ugyanazt hányféle képpen lehet megközelíteni.)

Ha innen közelíted a problémádat, hamar rájössz, hogy neked nem az a bajod, hogy a git nem tudja kezelni, hogy a két file változás után tök ugyanaz, hanem valójában 2x van meg ugyanaz a változás (hiszen két commit), emiatt nem lesz reprodukálható az út az alapállapot és a remote teteje között, mert eltérnek az állomások, és neked igazából csak semmi szükséged az egyikre (mert van egy másik, azonos tartalmú changed). Jelen esetben jellemzően arra, ami a gépeden volt mászkálás előtt, mert gondolom a laptopon utána csináltál még ezt-azt. Szóval tulajdonképpen azt akarod elérni, hogy a helyi pointered a remote tetejére mutasson. És akkor innen már (attól függően, hogy mennyire ismered a parancsokat), trivi:

git fetch #lehúzza a remote brancheket, de a pullal ellentétben nem basztatja a helyi pointert
git reset --hard origin/master #egyszerűen odabaszom a lokális pointert a távoli munka tetejére. A hard azért kell, mert vannak lokális changek, amiket le akarok szarni

Ha nincs még meg, hogy a távoli branchek állapotát így lehet használni, akkor megközelítheted úgy, hogy az utolsó helyi változtatásra nincs szükségem (erre ugye rá is jöttél: "ha nem commitoltam volna a módosítást lokálba"). Ezt egy `git reset --hard HEAD^1` megoldja, a helyi pointer eggyel visszább megy, az utolsó commit változásai pedig mennek a levesbe,  egyből mehet a `git pull`. --hard nélkül ott maradnak commitolatlanul, , de így már csak nyikorogna, hogy vannak local changek, és simán csak visszacsinálhatnád, ahogy akarod, akár kezeddel akár git resettel, amit már elárul a git status kimenete :) A HEAD^1 a parrent commit, de ha ez sincs meg, simán git log, kinézed az idt az akart állapotnak, aztán odaírod. Hiszen ez meg csak pointer aritmetika :)

---

Egyébként általában az a jó stratégia, hogy kerüljük, hogy párhuzamosan ugyanazon a branchen dolgozzunk, a branch olcsó (hiszen csak egy pointer ;), mehetnek a különböző témák külön, ha befejeztük, push, főleg, ha vándorlunk. Ha ez nem megy, pl mert többen dolgozunk rajta, akkor lefetcheled, és rebaseled az egyik állapotot a másikra. Jellemzően a remote tetejére a helyi véltozásaidat. Ez újra végig csinálja a már meglevő commitjaid a remote tetején (új commitok, új parentekkel), ettől kiegyenesedik a vonat (persze, ha konflict volt, akkor kitalálod mi legyen). Egy jó interaktív rebassel még a sorrendet is rendbe teheted. Viszont utána nincs mese, force push jön, szóval a másik oldalon lehet játszani a szopadékot :)

Na akkor mégegyszer: értem, hogy hogyan működik, és nem az a bajom, hogy "fájlokban gondolkodtam", hanem az, hogy előállt rutinhasználat mellett egy olyan állapot, amit egyszerűbb volt az-egészet-letöröl-és-újraklónoz-zal megoldani. Valószínű, ha ráfecséreltem volna pár napot, akkor találok megoldást, de nem ez a lényeg, hanem az, hogy NEM ÉRI MEG ennyi időt pazarolni rá, mivel a projektemmel akarok foglalkozni, és nem a tool lelkivilágát ápolgatni.

Ha innen közelíted a problémádat, hamar rájössz, hogy neked nem az a bajod

Nehogy már a nyúl vigye a vadászpuskát... Nem én vagyok a számítógépért, hanem a számítógép van énértem. Nehogy már a gép akarja eldönteni helyettem, hogy nekem mi is a bajom, ne vicceljünk már. Ez a gyökkettő ikújú átlag lúzernél működhet, de bármelyik tapasztalt fejlesztő/poweruser falra mászik ettől, ezt garantálom.

Olyan ez, mintha egy SQL programozótól elvárnád, hogy tudja, a MariaDB, Postgre vagy épp az SQLite milyen bitszintű adatmodellt használ az adattárolásra, ahhoz, hogy SQL queryket tudjon írni. Persze, jól jöhet ez az ismeret néhány nagyon nagyon kisarkított esetben, na de nem kell tudni egy rutinhasználat során.

Egyébként általában az a jó stratégia, hogy kerüljük, hogy párhuzamosan ugyanazon a branchen dolgozzunk, a branch olcsó (hiszen csak egy pointer ;), mehetnek a különböző témák külön

A branchnek iszonyat sok hátránya van, például rendszeresen beszívom, hogy branchváltásnál elmásznak az utolsó fájlmódosítás dátumok, ami enyhén szólva is idegesítő, mert alátesz a GNU/make-nek. A felhasználók is utálják, mert sosem tudják, hogy akkor most melyik változatot is kéne letölteniük, és csak gyártják a ticketeket. Ráadásul a szétdivergáló kódbázist újraegyesíteni sokszor szopás a köbön, ahogy Te is említetted.

Mindezek ellenére megvan a branchelés létjogosultsága, csak korántsem egy csodafegyver, ami minden bajra jó.

Na akkor mégegyszer: értem, hogy hogyan működik, és nem az a bajom, hogy "fájlokban gondolkodtam", hanem az, hogy előállt rutinhasználat mellett egy olyan állapot, amit egyszerűbb volt az-egészet-letöröl-és-újraklónoz-zal megoldani. Valószínű, ha ráfecséreltem volna pár napot, akkor találok megoldást, de nem ez a lényeg, hanem az, hogy NEM ÉRI MEG ennyi időt pazarolni rá, mivel a projektemmel akarok foglalkozni, és nem a tool lelkivilágát ápolgatni.

Nem egészen értem, hogy mire ez a sértődött hangnem, én csak segíteni akartam, hogy hogyan kell ezt megoldani. Nem nagyon kell meggyőznöd arról, hogy van vele baj, eleve én hoztam ezt fel :) De azért azt szeretném mondani, hamár, hogy önértékeléseddel ellentétben, nem, ha egy kósza véletlen commitot nem tudod, hogyn kell kezelni, és rá kéne  szánni pár napot, akkor nem, nem nem tudod hogy működik, mert akkor ez vagy megy rutinból, vagy ha nem, tudni fogod, mit írj a gugliba, aztán egy perc alatt megmondja.

Nehogy már a nyúl vigye a vadászpuskát... Nem én vagyok a számítógépért, hanem a számítógép van énértem. Nehogy már a gép akarja eldönteni helyettem, hogy nekem mi is a bajom, ne vicceljünk már.

Nézd, én azzal teljesen egyetértek, hogy a gép van értem, és nem fordítva, itt is leírtam már egy párszor. De itt most nem erről van szó. Arról van szó, hogy volt egy problémád a gitben levő adatokkal, amit a git eszköztárával kell megérteni, és kezelni.

Ez a gyökkettő ikújú átlag lúzernél működhet, de bármelyik tapasztalt fejlesztő/poweruser falra mászik ettől, ezt garantálom.

Tapasztalataim szerint ezzel pont a hátulgombolós fejlesztők szoptak szopni, a tapasztaltak már láttak láncolt listát is, gráfot is, obskúrus kretén APIt is, és megvan a megfelelő absztrakciós képességük, hogy ráültessék arra, amit a git csinál, megvonják a vállukat, egyszer megnézik, hogy kb hogy van, aztán használják. 

Olyan ez, mintha egy SQL programozótól elvárnád, hogy tudja, a MariaDB, Postgre vagy épp az SQLite milyen bitszintű adatmodellt használ az adattárolásra, ahhoz, hogy SQL queryket tudjon írni. Persze, jól jöhet ez az ismeret néhány nagyon nagyon kisarkított esetben, na de nem kell tudni egy rutinhasználat során.

A példa nem rossz, de amiről én beszéltem, az az a szint, hogy elvárom az sql programozótól, hogy tudja, hogy ebben az izében táblák vannak, relációk és queryk, hogy melyik join mit csinál, és hogy mik a jellemző seggbeharapások. Mert a git kb ugyanúgy egy adatbázis kezelő ám.

A branchnek iszonyat sok hátránya van, például rendszeresen beszívom, hogy branchváltásnál elmásznak az utolsó fájlmódosítás dátumok, ami enyhén szólva is idegesítő, mert alátesz a GNU/make-nek. A felhasználók is utálják, mert sosem tudják, hogy akkor most melyik változatot is kéne letölteniük, és csak gyártják a ticketeket. Ráadásul a szétdivergáló kódbázist újraegyesíteni sokszor szopás a köbön, ahogy Te is említetted.

Biztos rengeteg hátránya van, de hogy pl hogy jönnek ide a userek, azt nem is akarom tudni. 

Nem egészen értem, hogy mire ez a sértődött hangnem

Milyen sértődött hangnem?

önértékeléseddel ellentétben, nem, ha egy kósza véletlen commitot nem tudod, hogyn kell kezelni, és rá kéne szánni pár napot

Itt azért álljunk meg egy szóra. Sok sok éve használok git-et (lassan már egy évtizede), és elég kacifántos helyzeteket is megoldottam már benne. Ennek semmi köze ahhoz, hogy nem tartom mindig fejben az összes lehetséges kapcsolóját. Nem vagyok autista, ha egy adott kapcsolót sokáig nem kell használnom, akkor bizony elfelejtem, ahogy bármelyik más egészséges felnőtt.

tudni fogod, mit írj a gugliba, aztán egy perc alatt megmondja.

Nem, épp ez az (egyik) baj a git-tel, hogy ez nem igaz. Én vagyok az élő példa rá, hiába használtam már számtalanszor, hirtelen nem jutott eszembe, hogy "--hard" kell neki, és nem, nemcsak pár perc, de még negyed óra keresés után sem köpte ki egyik kereső sem, és a man pageben sem ugrott rá egyik keresés sem. Ha kiköpte volna, akkor a fejemhez csapok, hogy ja persze, az "overwrite"-ot vagy "force"-ot "hard"-nak hívja az az idióta git!

A gugli és a többi kereső használhatósága egyébként is meredeken ível lefelé már egy jó ideje; az, hogy neked kidobja a jó találot egy adott keresőszóra, egyáltalán nem azt jelenti, hogy ugyanarra a keresőszóra nekem is ki fogja. Mostanában ráadásul még konkrétan hibás, nemlétező találatok, AI hallucinációk is keverednek a kimenetbe, de ez más tészta. Napjaikra érvényét vesztette a "let me google for you" érvelés.

A példa nem rossz, de amiről én beszéltem, az az a szint, hogy elvárom az sql programozótól, hogy tudja, hogy ebben az izében táblák vannak, relációk és queryk, hogy melyik join mit csinál, és hogy mik a jellemző seggbeharapások. Mert a git kb ugyanúgy egy adatbázis kezelő ám.

Tudom, hogy alavetően egy db, pont azért hoztam ezt a példát. De a lényeget lefelejtetted: git-el ellentétben egy SELECT vagy INSERT query összerakásához nem kell feltétlenül ismerned az adatbázis belsős adatábrázolását meg csínnyját-bínnyját. A git-nél teljesen hiányzik ez az absztrakciós szint, ott az adatmodell egy-az-egyben lett kivezetve a kapcsolókra, ráadásul a kapcsolók sem épp intuitív módon lettek elnevezve.

Biztos rengeteg hátránya van, de hogy pl hogy jönnek ide a userek, azt nem is akarom tudni.

Pedig nem ártana tudnod, ha nemcsak a két szép szemedért magadnak gyártod a repót, hanem másokkal is meg akarod osztani.

Konkrét példa: az egyik Open Source projektemnél áttettem a binárisokat egy külön branch-be, hogy amikor a felületen a Download zip-re kattint valaki, csak a forrás legyen benne (a binárisokra mutató linkek a readme-ben, amik korábban is ott voltak már, át lettek írva). Hiába, utánna jöttek az issue-k, hogy nem értik, eltűnt, most mi van, hogy töltsem le stb., pedig szó sincs arról, hogy szerteágazó brancheket csináltam volna, csakis a fordítás végeredményét raktam külön, a letöltési linkek is ugyanott maradtak (csak más URL-el), de az átlag felhasználóknak már ez is túl sok volt.

Milyen sértődött hangnem?

Egészen úgy hangzottál (most is), de akkor nem :)

Itt azért álljunk meg egy szóra. Sok sok éve használok git-et (lassan már egy évtizede), és elég kacifántos helyzeteket is megoldottam már benne. Ennek semmi köze ahhoz, hogy nem tartom mindig fejben az összes lehetséges kapcsolóját. Nem vagyok autista, ha egy adott kapcsolót sokáig nem kell használnom, akkor bizony elfelejtem, ahogy bármelyik más egészséges felnőtt.

Nem, épp ez az (egyik) baj a git-tel, hogy ez nem igaz. Én vagyok az élő példa rá, hiába használtam már számtalanszor, hirtelen nem jutott eszembe, hogy "--hard" kell neki, és nem, nemcsak pár perc, de még negyed óra keresés után sem köpte ki egyik kereső sem, és a man pageben sem ugrott rá egyik keresés sem. Ha kiköpte volna, akkor a fejemhez csapok, hogy ja persze, az "overwrite"-ot vagy "force"-ot "hard"-nak hívja az az idióta git!

Én is ilyen vagyok, de szerintem ez az, amit az ember nem felejt el, mert a git 1x1 részéhez tartozik, kevés annál egyszerűbb rutin feladat van, mint kidobni egy nem kellő commitot, szóval ide a rozsdás bökőt, hogy ha beírod gugli barátunkba, hogy git remove last commit, akkor ki fogja dobni a git reset-et, meg hogy itt valamiért --hardnak hívják, hogy nőjön rá köröm. Persze feltéve, hogy érted, hogy ezt kell kérdezni, meg érted egyébként a szavakat, amikkel operál.

Tudom, hogy alavetően egy db, pont azért hoztam ezt a példát. De a lényeget lefelejtetted: git-el ellentétben egy SELECT vagy INSERT query összerakásához nem kell feltétlenül ismerned az adatbázis belsős adatábrázolását meg csínnyját-bínnyját. A git-nél teljesen hiányzik ez az absztrakciós szint, ott az adatmodell egy-az-egyben lett kivezetve a kapcsolókra, ráadásul a kapcsolók sem épp intuitív módon lettek elnevezve.

Ott van köztünk a különbség, hogy szerintem a commitok, a parentje, a mi a branch, mi a tag, mi a merge és mi a rebase, meg hogy hogyan tudok a gráfban mozogni, azok szerintem az a szint, ami az sqlnél a mi a tábla, mi a reláció, mik azok a függvények, mi az a tárolt eljárás, és ilyesmik. Mert alapvetően ezzel dolgozik, aki dolgozik benne. Gitnél is ott van hátul még a reflog, az az a szint (nem teljesen, de a példa kedvéért legyen), ami az sql "belsős adatábrázolás csínja-bínja". És igen, alapvető probléma, hogy tudok a létezéséről, az meg főleg, hogy időnként hozzá kell nyúlni. És igen, az interfész brainfuck, és igen, az, hogy normálisan használni rebase jellegű operációk nélkül kb lehetetlen, az baj, ezzel kezdtem kb a szálat :)

Pedig nem ártana tudnod, ha nemcsak a két szép szemedért magadnak gyártod a repót, hanem másokkal is meg akarod osztani.

Konkrét példa: az egyik Open Source projektemnél áttettem a binárisokat egy külön branch-be, hogy amikor a felületen a Download zip-re kattint valaki, csak a forrás legyen benne (a binárisokra mutató linkek a readme-ben, amik korábban is ott voltak már, át lettek írva). Hiába, utánna jöttek az issue-k, hogy nem értik, eltűnt, most mi van, hogy töltsem le stb., pedig szó sincs arról, hogy szerteágazó brancheket csináltam volna, csakis a fordítás végeredményét raktam külön, a letöltési linkek is ugyanott maradtak (csak más URL-el), de az átlag felhasználóknak már ez is túl sok volt.

Ne haragudj, de ez szerintem azért van, mert te valamit teljesen rosszul fogsz. Mit keresnek egyáltalán binárisok a gitben? Mit keres valami separate branch, ami folyamatosan van, és arra jó, hogy egy másik egy része generáljon bele dolgokat? Persze, hogy nem érti senki, hogy ez miért branch, mert sose ágazott el igazán, és soha nem akar majd visszamergelődni se. Egyáltalán, mi a búbánatot keresnek a release artifactjaid a gitben?

Igen, a gitnek az is baja, hogy ad-hoc használva egész nagy kupi alakul ki egész gyorsan, kell rá valami stratégia, de erre azért ez igen atipikus. Én "userként" egy bármilyen repóról alapvetően nem is akarok hallani, max a githubon oldalt a releasek erejéig. Ha mégis kell, akkor branch ügyileg kb a master, meg esetleg valami release-* vagy version-* szerű branchek érdekelnek belőle, az, hogy a binárisok egy valamilyen branchen vannak, azt ne haragudj, nem tudom szebben megfogalmazni: agyfasz.

kevés annál egyszerűbb rutin feladat van, mint kidobni egy nem kellő commitot,

Rutin??? Egy kezemen meg tudom számolni, hogy az elmúlt kb egy évtizedben hányszor volt erre szükségem. Nem sokszor. A rebase-t meg a squash-t nagyságrendekkel többször használom.

rozsdás bökőt, hogy ha beírod gugli barátunkba, hogy git remove last commit

Egyrészről, mint írtam, az "overwrite" ill. "force pull" vonalon kerestem, másrészről most direkt kipróbáltam, rákerestem erre a kifejezésre, a legelső találat ez (nálam legalábbis, nálad valószínűleg tök más találok szerepelnek). Ez az oldal kismillió lehetséges variációt felsorol, reflog, amend stb., a "reset --hard" csak egy a sok-sok válasz közül, ráadásul nem is az elfogadott megoldás, és jócskán le kell görgetni hozzá. Egyáltalán nem egyértelmű a válaszokból, hogy az kellett volna az esetemben, csak onnan tudom, mert évekkel ezelőtt már használtam, és amikor írtad, akkor beugrott (de sajna amikor szükség lett volna rá, na pont akkor ott nem jutott eszembe).

azok szerintem az a szint, ami az sqlnél a mi a tábla, mi a reláció, mik azok a függvények, mi az a tárolt eljárás, és ilyesmik.

Na ez a tévedésed oka. Nem, ez már mind egy tök magas absztrakciós szint. Ami megfelel (és amit csínyjának-bínyjának hívtam), az az, hogy az indexálás implementáció milyen adatstruktúrát és algoritmust használ és ebből kifolyólag milyen aszimptotikus jellemzőkkel bír, vagy például az, hogy az SQLlite3 sztringként tárolja a lemezen a számokat, nem integerként, stb.. Ez az adatmodell tárolási szintje, az, hogy "sql tábla", már egy nagyon nagyon magas absztrakciós szint, aminek nincs köze ahhoz, hogy igazából hogyan is tárolódik a lemezen.

És igen, az interfész brainfuck, és igen, az, hogy normálisan használni rebase jellegű operációk nélkül kb lehetetlen, az baj, ezzel kezdtem kb a szálat :)

Igen, ebben egyetértük, de élvezem, hogy végre egy tartalmas és értelmes szakmai beszélgetést folytatunk, ami manapság egyre inkább hiánycikk a HUP-on ;-)

Mit keresnek egyáltalán binárisok a gitben?

Látom nem ismered a githosting világát. Rövid válasz: kényszerből.

Például:
- a release taghez nem adható meg csatolmány, csak URL, tehát a binárisokat tárolnod kell valahol, és az a git repó, mert más tároló nincs
- van, ahol a CI-CD (ami a bináris URL-jét szolgáltatná) nem működik alapból, ahhoz meg kéne adnod pl. a bankkártya adataidat (ami egy rossz scam oldal szintű bazi nagy red flag, ráadásul sokszor még azzal együtt sem működik)
- a honlapon (ami szintén a git repóból generálódik), mindenképp elvárják a közvetlen "Letöltés" gombot (link a releasere nem elég), mert a programozók lusták, 99,9%-uk nem fordít, csak ha feltétlenül muszáj
- webassembly esetében sincs más lehetőséged a XSS tiltás miatt (valami idióta másik TLD-re rakta a repót (.com/.org) és a kigenerált honlap webserverét (.io/.page), a többi hülye szolgáltató meg gondolkodás nélkül majmolja ezt, így a wasm bináris hivatkozás sehogy máshogy nem tud működni egyetlen githostingon se. A HTTP fejlécbe ugyanis nem tudsz belenyúlni, hogy explicit engedélyezd, ezt egyik githosting sem engedi)

Én "userként" egy bármilyen repóról alapvetően nem is akarok hallani, max a githubon oldalt a releasek erejéig.

Szóval egyetértesz, szerinted is zavaró a sok branch.

Ha mégis kell, akkor branch ügyileg kb a master, meg esetleg valami release-* vagy version-* szerű branchek érdekelnek belőle, az, hogy a binárisok egy valamilyen branchen vannak, azt ne haragudj, nem tudom szebben megfogalmazni: agyfasz.

Az nem PC, "master" branch már évek óta nincs sehol, és mit gondolsz, mit tartalmaznak a "release" branchek, ha nem a binárisokat? (release branch != release tag)

Mégegyszer, az, hogy a git repóban vannak a binárisok, nem jókedvemből van, hanem kényszermegoldás, mivel néhány githosting semmi mást nem támogat.

Rutin??? Egy kezemen meg tudom számolni, hogy az elmúlt kb egy évtizedben hányszor volt erre szükségem. Nem sokszor. A rebase-t meg a squash-t nagyságrendekkel többször használom.

Ezek szerint nagyon másképp dolgozunk :) 

Egyrészről, mint írtam, az "overwrite" ill. "force pull" vonalon kerestem, másrészről most direkt kipróbáltam, rákerestem erre a kifejezésre, a legelső találat ez (nálam legalábbis, nálad valószínűleg tök más találok szerepelnek). Ez az oldal kismillió lehetséges variációt felsorol, reflog, amend stb., a "reset --hard" csak egy a sok-sok válasz közül, ráadásul nem is az elfogadott megoldás, és jócskán le kell görgetni hozzá. Egyáltalán nem egyértelmű a válaszokból, hogy az kellett volna az esetemben, csak onnan tudom, mert évekkel ezelőtt már használtam, és amikor írtad, akkor beugrott (de sajna amikor szükség lett volna rá, na pont akkor ott nem jutott eszembe).

Ennek az első válasza tök jó, a git reset --hard nélkül is pont megoldja, ott fogja hagyni az uncommited changeid, de azzal már gondolom tudsz mit kezdeni (azt még a git status kimenete is elmondja, hogy kell tőle megszabadulni.

Na ez a tévedésed oka. Nem, ez már mind egy tök magas absztrakciós szint. Ami megfelel (és amit csínyjának-bínyjának hívtam), az az, hogy az indexálás implementáció milyen adatstruktúrát és algoritmust használ és ebből kifolyólag milyen aszimptotikus jellemzőkkel bír, vagy például az, hogy az SQLlite3 sztringként tárolja a lemezen a számokat, nem integerként, stb.. Ez az adatmodell tárolási szintje, az, hogy "sql tábla", már egy nagyon nagyon magas absztrakciós szint, aminek nincs köze ahhoz, hogy igazából hogyan is tárolódik a lemezen.

Ebben nem feltétlen értünk egyet. Vagy csak másképp nézzük :) A git ezen a szinten ad adatstruktúrákat, ezen a szinten érdemes gondolkodni róla. Azt aláírom, hogy ez helyenként egy kicsit lejebb van, mint kéne, és a parancsok ostobák tudnak lenni, mert ez normálisan kb tényleg valami git undo commit vagy ilyesmi kéne legyen, az sql egy sokkal szerencsésebb nyelv. Illetve szerintem ott értettél egy kicsit félre, hogy a hozzászólásom ezen része nem arról szólt, hogy védjem a gitet, hanem arról, hogy elmondjam, hogy szerintem hogy érdemes róla gondolkodni, mert mivel ez a defakto sztenderd (pl a 12x szimpibb mercurial helyett), ezért ezt kell megtanulni használi.

Látom nem ismered a githosting világát. Rövid válasz: kényszerből.

Őőő, hátizé.  :)

- a release taghez nem adható meg csatolmány, csak URL, tehát a binárisokat tárolnod kell valahol, és az a git repó, mert más tároló nincs

A githubba simán bele lehet tenni fileokat a releasebe, a kicsi kezeddel, meg az apin keresztül is.

- van, ahol a CI-CD (ami a bináris URL-jét szolgáltatná) nem működik alapból, ahhoz meg kéne adnod pl. a bankkártya adataidat (ami egy rossz scam oldal szintű bazi nagy red flag, ráadásul sokszor még azzal együtt sem működik)

Igen, az artifactok előállítása jellemzően a CI dolga, annak kéne oda tenni valahova a githez. Az, hogy te nem vagy hajlandó ilyet használni, az nem a git baja. (Gitlabon pl szerintem valamennyi CI idő még mindig jár ingyen, és integráltan van)

- a honlapon (ami szintén a git repóból generálódik), mindenképp elvárják a közvetlen "Letöltés" gombot (link a releasere nem elég), mert a programozók lusták, 99,9%-uk nem fordít, csak ha feltétlenül muszáj

Amit nyugodtan lehet gondolom deplinkelni a githubról pl.

- webassembly esetében sincs más lehetőséged a XSS tiltás miatt (valami idióta másik TLD-re rakta a repót (.com/.org) és a kigenerált honlap webserverét (.io/.page), a többi hülye szolgáltató meg gondolkodás nélkül majmolja ezt, így a wasm bináris hivatkozás sehogy máshogy nem tud működni egyetlen githostingon se. A HTTP fejlécbe ugyanis nem tudsz belenyúlni, hogy explicit engedélyezd, ezt egyik githosting sem engedi)

Webassemblyhez nem értek, szóval biztosan igazad van, bár élnék a gyanúperrel, hogy megint valamit máshol akarsz megoldani, mint ahol kéne.

Általában is úgy érzem, hogy ezek a bajok egyrészt abból adódnak, hogy olyan dolgokat akarsz csinálni, amik nem oda valóak, ugyan meg vannak oldva, de neked azzal valami egyéb bajod van, ráadásul nem nagyon van közük a githez mint olyanhoz, max a ráépülő extra szolgáltatásokhoz.

Egyébként egész nagy tételben szoktam mindenfélét ezekről a helyekről használni, és kurvára nem emlékszem, hogy bármikor is valami random branchen kellett volna keresgélnem releaset, de készségesen elhiszem, hogy a te nieced valami egyedi hely :)

Szóval egyetértesz, szerinted is zavaró a sok branch.

Nem. Vagy legalábbis ezért nem, userként keresztbe leszarom, hogy hány branch van még, az mindenkinek privát magánügye kb, csak ne kelljen nekem ebben turkálnom úgy, ahogy senki más nem várja el. Bár őszintén szólva, ha le van írva, hogy binárisok a kiskutyafasza branchen vannak, akkor megvonnám a válam, aztán lehúznám onnan.

Ettől még az ilyen összeütközések kezelésére bizony teljesen jó, ha amit csinálsz elbrancheled. Igen, akár localban is, a feature branchról is, mert akkor majd rendezed a mi van kivel kérdést squashostól rebasestől mergestől, mikor már ott tartasz.

Az nem PC, "master" branch már évek óta nincs sehol,

Komolyan láttam, hogy meg fogunk érkezni bringatárolót festeni :) 

és mit gondolsz, mit tartalmaznak a "release" branchek, ha nem a binárisokat? (release branch != release tag)

Ha van ilyen, akkor általában az adott major/minor verzió release óta bekerült, jellemzően cherrypickelt (vagy valami bugfix branchről több helyre mergelt, bár az pfujj) bugfix commitok, és patch/minor release tagek (tudom, azok gyakorlatilag nem a branchen vannak). 

Mégegyszer, az, hogy a git repóban vannak a binárisok, nem jókedvemből van, hanem kényszermegoldás, mivel néhány githosting semmi mást nem támogat.

A világ jelentős része valahogy mégiscsak nem így csinálja ezt. :) 

Azt aláírom, hogy ez helyenként egy kicsit lejebb van, mint kéne, és a parancsok ostobák tudnak lenni, mert ez normálisan kb tényleg valami git undo commit vagy ilyesmi kéne legyen

Igen, ezt már megállapítottuk, hogy egyetértünk.

A githubba simán bele lehet tenni fileokat a releasebe, a kicsi kezeddel, meg az apin keresztül is.

Mégegyszer: nem minden githosting tudja ezt, és amit beraksz a kicsi kezeddel, azokhoz is kell egy URL, tehát a neten kell tárolnod a binárisokat. Csatolmány hiányában csak a git repó marad erre, mint mondottam volt.

Amit nyugodtan lehet gondolom deplinkelni a githubról pl.

Nem a link a kérdés, mégegyszer: azokhoz is kell egy URL, tehát a neten kell tárolnod a binárisokat. Csatolmány hiányában csak a git repó marad erre, mint mondottam volt.

Gitlabon pl szerintem valamennyi CI idő még mindig jár ingyen, és integráltan van

Ja, ha minden repódhoz külön nyitsz egy bankszámlaszámot és igényelsz egy külön bankkártyát, aminek az összes adatát önként és dalolva átadod a gitlab-nak. Mert ugye naívan elhiszed nekik, hogy nem válik egyik napról a másikra fizetőssé, és hogy kisdobos becsszó ígérik, meglopni sem fognak...

Aki ennek bedől, az meg is érdemli, hogy kirabolják, ha máskor nem, majd amikor data breach lép fel (ami csupán idő kérdése, mivel most már banki adatokat is tárolnak, egyre több cracker cuppan rá; abba meg, hogy ezzel GDPR-t sértenek, inkább ne is menjük bele).

bár élnék a gyanúperrel, hogy megint valamit máshol akarsz megoldani, mint ahol kéne.

Nem. A legtöbb githosting egy dedikált branchből csinálja a honlapot, ami ráadásul jellemzően nem is állítható, a neve "be van égetve". Nem létezik olyan, hogy máshol kéne megoldani, nincs máshol. (És az XSS miatt sem a normál git repó, sem külső statikus tárhely, pl cdn sem jöhet szóba, a js-eknek és a wasm binárisoknak azon az oldalon kell lenniük, mint az index.html-nek.)

ráadásul nem nagyon van közük a githez mint olyanhoz, max a ráépülő extra szolgáltatásokhoz.

Nyilván, de mit számít ez, amikor a ráépülő szolgáltatásokkal együtt használhatod csak? Semelyik githosting sem engedi meg, hogy alányúlj a felületének, és az ott kikényszerített megszorításokat megkerüld.

csak ne kelljen nekem ebben turkálnom úgy, ahogy senki más nem várja el.

Pontosan. Tehát szerinted is zavaró, ha sok a branch. Elárulom, senki sem szeret a branchekben turkálni, ezzel nem vagy egyedül.

Ha van ilyen, akkor általában az adott major/minor verzió release óta bekerült, jellemzően cherrypickelt (vagy valami bugfix branchről több helyre mergelt, bár az pfujj) bugfix commitok, és patch/minor release tagek (tudom, azok gyakorlatilag nem a branchen vannak).

Látom, nem vagy képben:
- release tag - ez egy tag, ami a commitokat tartalmazza, a forrást egy adott időpontban megjelölve
- release adatlap - ennek semmi köze a git-hez, a githosting adja. Tipikusan tarball linket ad csak a bugfixelt forrásra (ez automatikus, és a release tag-el megjelölt verzióra mutat), valamint szokott tartalmazni letöltés linket binárisokra (ez nem automatikus, és a link URL-jét minden esetben Neked kell biztosítani)
- release branch - ez nem commitokat tárol (az a release tag ugyanis), hanem azokat a bináris fájlokat, ahová a release adatlap linkjei mutatnak (ez szokott külsős statikus tárhelyen is lenni, ha az megoldható. Ha nem oldható meg, akkor marad a git repó, mint egyetlen lehetséges tároló)

A világ jelentős része valahogy mégiscsak nem így csinálja ezt. :)

Nézzünk meg pár repót, amibe szoktam kontributálni, vagy gyakran használom:
- qemu - egyáltalán nem használ release-ket
- Linux kernel - egyáltalán nem használ release-ket, csak tag-eket
- RaspiOS Linux fork - egyáltalán nem használ release-ket, a binárisok git repóban vannak
- ScummVM - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs
- SQLite - egyáltalán nem használ release-ket
- FlareRPG - egyáltalán nem használ release-ket
- freedesktop-sdk - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs
- Inkscape - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs
- ...stb.

Szóval ja, a "világ jelentős része" úgy oldja meg, hogy leginkább egyáltalán nem is használja... (Jellemzően akkor szokott megoldva lenni, ha maguk üzemeltetik a git-et, gitweb-et, és a CI-t is, azaz nincs külsős harmadik fél, minden házon belül van, pl: coreboot, gnome stb., vagy fizetnek egy külsős (githostingtól független) tárhelyért, ami egy kis non-profit Open Source repó esetén eleve ki van zárva, mert nem tudom)

Mégegyszer: nem minden githosting tudja ezt, és amit beraksz a kicsi kezeddel, azokhoz is kell egy URL, tehát a neten kell tárolnod a binárisokat. Csatolmány hiányában csak a git repó marad erre, mint mondottam volt.

Nézd, én elmegyek a githubon egy repora, megnyomom a new release gombot, aztán odabaszok egy filet teljesen függetlenül attól, hogy mi van a repoban, akkor az ott lesz. Nem kell URL, nem kell semmi baszás.

Nem a link a kérdés, mégegyszer: azokhoz is kell egy URL, tehát a neten kell tárolnod a binárisokat. Csatolmány hiányában csak a git repó marad erre, mint mondottam volt.

És utána a fenti izére kapok egy linket, amit már nyugodtan beírhatok oda, ahova csak akarom. De igen, továbbra is, persze, ott kell tárolni? És? Ennek mi a búbánat köze van a githez?

Ja, ha minden repódhoz külön nyitsz egy bankszámlaszámot és igényelsz egy külön bankkártyát, aminek az összes adatát önként és dalolva átadod a gitlab-nak. Mert ugye naívan elhiszed nekik, hogy nem válik egyik napról a másikra fizetőssé, és hogy kisdobos becsszó ígérik, meglopni sem fognak...

Tehát meg van ez oldva, csak te butthurt much, mert neked ingyen kell. :) Ráadásul a gitlab pl most is ad 400 perc comupte timeot, nem kell hozzá bankkártya, gitlab kb detto, kiscsillió CI van, ami open sourcenak ad puszira valami időt mindenféle bankkátya nélkül. 

Nem. A legtöbb githosting egy dedikált branchből csinálja a honlapot, ami ráadásul jellemzően nem is állítható, a neve "be van égetve". Nem létezik olyan, hogy máshol kéne megoldani, nincs máshol. (És az XSS miatt sem a normál git repó, sem külső statikus tárhely, pl cdn sem jöhet szóba, a js-eknek és a wasm binárisoknak azon az oldalon kell lenniük, mint az index.html-nek.)

Ja, ami kifejezetten page forrásra való, és nem véletlen teszi mindenki egy külön repositoriba, nem keveri be a pages tartalmát a forráskódba. És ezeknek a repóknak a tartalmát a nehézség se nézegeti userként, a kigenerált izét nézem

Nyilván, de mit számít ez, amikor a ráépülő szolgáltatásokkal együtt használhatod csak? Semelyik githosting sem engedi meg, hogy alányúlj a felületének, és az ott kikényszerített megszorításokat megkerüld.

Azt számítja, hogy én a gitről, meg arról beszélek, hogy hogyan használjuk forráskód managementre, te meg nekiállsz rugózni azon, hogy azért szar a branching, mert a github pages szarul abuzálja szerinted.

Pontosan. Tehát szerinted is zavaró, ha sok a branch. Elárulom, senki sem szeret a branchekben turkálni, ezzel nem vagy egyedül.

Továbbra sem. Mert egy ismeretlen repóban egyáltalán nem kell random branchek alapján turkálnom. Főleg nem binárisokért.

Látom, nem vagy képben:
- release tag - ez egy tag, ami a commitokat tartalmazza, a forrást egy adott időpontban megjelölve
- release adatlap - ennek semmi köze a git-hez, a githosting adja. Tipikusan tarball linket ad csak a bugfixelt forrásra (ez automatikus, és a release tag-el megjelölt verzióra mutat), valamint szokott tartalmazni letöltés linket binárisokra (ez nem automatikus, és a link URL-jét minden esetben Neked kell biztosítani)
- release branch - ez nem commitokat tárol (az a release tag ugyanis), hanem azokat a bináris fájlokat, ahová a release adatlap linkjei mutatnak (ez szokott külsős statikus tárhelyen is lenni, ha az megoldható. Ha nem oldható meg, akkor marad a git repó, mint egyetlen lehetséges tároló)

De, kb igen, csak te elkezdtél a git helyett másról beszélni, és nem fogtam fel :) 

Nézzünk meg pár repót, amibe szoktam kontributálni, vagy gyakran használom:
- qemu - egyáltalán nem használ release-ket
- Linux kernel - egyáltalán nem használ release-ket, csak tag-eket
- RaspiOS Linux fork - egyáltalán nem használ release-ket, a binárisok git repóban vannak
- ScummVM - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs
- SQLite - egyáltalán nem használ release-ket
- FlareRPG - egyáltalán nem használ release-ket
- freedesktop-sdk - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs
- Inkscape - van ugyan release, de csak forrás tarballok, binárisra még csak link sincs

És ezek közül melyiknek kell egyáltalán a repója környékére mennem userként, pláne valami branchet keresnem, ha használni akarom? Rohadt vicces, hogy cáfolni akarod, amit mondok, aztán hozol egy rakás példát, ami pont azt támasztja alá, amit mondtam: nincsenek a gitben, meg a környékén se a release artifactok, mert a git repóban a forráskód van. Nem fogom végignézni az összeset, de nem túl meglepő módon a qemunal pl nincsenek releasek, cserében van egy link a homepagere, ahol van egy kibaszott nagy piros gomb a releasekre meg a downloadra.

Az egyetlen példa, ahol a release binárisok a git repóban vannak, az egy kifejezetten csak binárisokat tartalmazó repó, és egyáltalán nincsen benne semmilyen obskurus branch :)

Ráadásul a gitlab pl most is ad 400 perc comupte timeot, nem kell hozzá bankkártya

Mondom, nem vagy járatos githostingban. De bizony kell hozzá, ráadásul nem is akármilyen, a repó owner nevére kell kiállítva legyen, ezt még külön is ellenőrzik. Az nem játszik, hogy megadod a magán bankkártyaszámodat, azt nem fogadják el (csak a magán repóid esetén), egy projekthez alapítvány vagymittomén mi kell, önálló bankkártyával a projekt nevére (lásd a korábban linkelt sirámokat, fogadjunk, rá se kattintottál a linkre!).

Ja, ami kifejezetten page forrásra való, és nem véletlen teszi mindenki egy külön repositoriba

Nem repó, branch (doksi). Szóval a pages nem zavar, de egy binaries branch már igen?!?

Azt számítja, hogy én a gitről, meg arról beszélek, hogy hogyan használjuk forráskód managementre, te meg nekiállsz rugózni azon, hogy azért szar a branching, mert a github pages szarul abuzálja szerinted.

Látom, semmit sem értettél meg abból, amit írtam. Azt kérdezted, hogy hogy kerül bináris a gitbe, amire a válaszom az volt, hogy a githosting limitációi miatt, erre ilyen alpári hangon válaszolsz.

-------------------------------------------------------------------

De tudod mit, miszter nagyokos? Játszunk egy gondolatkísérletet!

Egy induló non-profit, FOSS projekt felelőse vagy. Mint ilyen, még nem kaptál semmi támogatást (mire is adtak volna), tehát a rendelkezésedre álló büdzsé 0 Ft. Azaz a megoldáshoz nem használhatsz fizetős szolgáltatást, emiatt a projektnek nincs bankszámlája, se bankkártyája, se mobilja, mivel ezek mind fizetősek lennének ugyebár.

A feladat: adj megoldást arra, hogy a non-profit FOSS projekt beinduljon, a forrása web-en és git-en egyaránt elérhető legyen, valamint legyen egy honlapja, lefordított binárisra mutató "Letöltés" linkkel, annélkül, hogy git repóba raknád a binárist!

Várom a megoldásaidat!

Megjegyzés: a github-ot buktad, mert hiába tud csatolmányt, a 2FA-hoz mobil kell; a gitlab-ot buktad, mert nincs bankkártyád a CI-hez, a csatolmányt meg nem tudja. De lássuk, hogy oldod meg binárisokat tartalmazó git branch nélkül! Hajrá! Bármelyik githostingot használhatod a megoldáshoz!

Megjegyzés2: ez nem valami légbőlkapott példa, hanem nagyon is életszerű, amivel MINDEN induló FOSS projekt kénytelen szembesülni.

A gitlabhoz nem kell mobil a 2FAhoz, két perce léptem be rá yubikey tokenemmel. De ha kéne is, akkor mi van, már telefonom se lehet? Meg nem mehetek el bármelyik istenverte ingyen hostingra, amivel tele van a net, nem bérelhetek magamnak egy fostos öt dolláros vpst a hobbinak, nem állhatok neki monduk egy aws free tiernek egy évig, és természetesen nem használhatom a saját bankártyámat se, hiszen azt mindenki azonnal ellopja és átvág. Nem használhatom mittomém én a circle ci-t, (pl arra vastagon rá van írva, hogy no credit card required, de gondolom van még egy köbvödör free tier), nincs százmillió ingyenes weboldal csináló izé, amitre feltölthetnéld az otthon lefordított binárist, semmi

Ne haragudj, de ez még így is nevetséges, hogy szar a git branch, mert neked alusipkád van, és nincs havi fasz tudja, két kávéd ára a hobbidra valami vps szolgáltatónál, ami ezeket a nyomorokat megoldja, de még így is csak azt sikerült előadnod, hogy bele kell rakjam mindenképp egy git repoba, nem azt, hogy a forráskóddal együtt kell legyen valami elbaszott branchen :)

Nem repó, branch (doksi). Szóval a pages nem zavar, de egy binaries branch már igen?!? 

Ezt azóta tetted be: nem, nem zavar, mert az, hogy a pageshez van egy külön repó, amiben az van, ami oda kell, az tiszta, és userként le tudom szarni, hogy mi van a repoban. Az meg, hogy van egy branch, aminek soha semmi köze nincs a forráskódhoz, ami mellette van, mert artifact, az meg egy marhaság. 

Látom, semmit sem értettél meg abból, amit írtam. Azt kérdezted, hogy hogy kerül bináris a gitbe, amire a válaszom az volt, hogy a githosting limitációi miatt, erre ilyen alpári hangon válaszolsz.

Szóval mégiscsak butthurt :) 

Nem látom, hogy bármiféle működőképes alternatívával álltál volna elő.

A vitát majd akkor folytatjuk, ha kaffogás helyett prezentálsz linket egy olyan repóra és honlapra, ami teljesíti a projekttel szemben támasztott összes követelményt.
Amíg erre nem vagy képes, addig semmi súlya sincs a szavaidnak.

?

Ott a github, használhatod. Ott a circleci, használhatod, nem kell credit card, rá lehet kötni a githubra, rá lehet kötni a gitlabra. Ott a wordpress.com, a cloudflare free tier, meg még ki tudja hány másik, lehet rajta honlap. Még az ilyen teljesen irreleváns nehezítésekkel is, hogy nem használhatom a telefonomat 2FA-ra hozzá :) De persze, sőt, a számítógépet, amin írom is szerezzem be ingyen, nem?

Ráadásul nem ez volt a kérdés, az volt a kérdés, hogy miért kellene valami fene tudja branchen tartani a kód repojában a binárisokat?