HOVD 2016 - Kedvenc verziókezelő rendszer

HUP

bazaar
1% (6 szavazat)
clearcase
1% (4 szavazat)
cvs
3% (19 szavazat)
git
77% (581 szavazat)
gnu arch
1% (11 szavazat)
mercurial
2% (17 szavazat)
perforce
0% (2 szavazat)
rcs
0% (2 szavazat)
subversion
13% (95 szavazat)
team foundation server
2% (15 szavazat)
Összes szavazat: 752

( mortein79 | 2016. 12. 11., v – 13:10 )

:(( Hogy lehet a bazaar csak 2 (már amikor ezt írom) ? hg is siralmas... mindenki ebbe a gitbe van belezúgva...

Lehetne egyenletesebb, ennyire nem király a git azért szerintem. Bár a github nem rossz, de a launchpad sem.

Azt gondolom, az emberek nagy része keveset ismer.

Ez rám biztos igaz. Régebben használtam a CVS-t, a saját (one-man) projekteimre a git-et. Miért? Mert mindent tud, ami nekem kell (bár valójában mindegyik tudja), meg kb. ez van mindenhol. Mivel mást igazán nem ismerek, így a git a kedvenc.

Ha már kibeszélő show-t tartunk azt is emesélhetni valaki hogy mi a baj a git-el :)

Úgyértem: használtam már sok mindent (svn, clearcase, bazaar, hg, tfs) de valahogy mind közül a git messze a leg kényelmesebb. Nem véletlen ennyire népszerű. Nem értem ez miért baj?

Nem tudom például megérteni azt a három kollégát, aki a clearcase-re adta le a voksát :) Igen, napi szinten szívok vele, tudom miről beszélek. ;) Még ha a hg-r mondja valaki akkor az rendben van.

Bazaar.. Szegénynek a lassúsága lett a veszte, pedíg ő volt az első dvcs amit használtam. De aztán miután sok órát néztem üveges szemekkel a mozdulatlan terminált, agyvérzés helyett git-re váltottam (ahol tehetm) és azóta szebb a világ :)

nekem a legnagyobb problemam a gittel az, hogy nem ad biztonsagot
alig par hete hasznaltuk a repot, mikor feltunt hogy az egyik commitom eltunt, hiaba kerestem
aztan a ticketing system linkjen keresztul meglett, de a branchen nem latszott
jol le lettem ott is hulyezve hogy marpedig ilyen nincs
aztan fel oraval kesobb kozolte az engem lehulyezo kollega hogy "jaaaa, pushminuszeffeltem, bocs"

szoval innentol en semmit nem mernek a gitre bizni amit kesobb meg latni akarok...
persze nyilvan le lehet tiltani (masteren nalunk most mar hal' istennek le van), de azzal meg gyakorlatilag a git osszes tenyleg jo feature-et kinyirod (pl. fixupok, rebase, stb)

A közösen használt repo-t annak megfelelően kellett volna létrehozni...

"persze nyilvan le lehet tiltani (masteren nalunk most mar hal' istennek le van), de azzal meg gyakorlatilag a git osszes tenyleg jo feature-et kinyirod (pl. fixupok, rebase, stb)"

Nem nyírod ki, a saját lokális repódban továbbra is azt csinálsz, amit akarsz, és vígan átírhatod a nem publikált history-t.

es a lokalis repobol mikor kuldom fel a "fo" repoba? miutan vegeztem a sajat gepemen a fejlesztessel, amihez senki mas nem nyul hozza?
ez egy emberes projectnel biztos tok jol mukodik, de nalunk egy-egy branchen tobben is dolgoznak egyszerre

raadasul ha csak lokalis repoba dolgozol, az megint csak lof@sz, veletlen letorolsz egy konyvtarat vagy megdoglik a vinyo, es megy a levesbe a komplett munkad?

Szerintem az egy jó ökölszabály, hogy nem szabad force pushol egy olyan ágba, ahova más is szokott pusholni (tehát nem csak olvassa). Teljesen jogos a kifogásod a fenti eset miatt, volt egy rossz tapasztalatod, amitől nem védett meg a git. Sajnos ez van, a kollégád hibázott, nem te, de ettől még a force push, ill. a rebase (és társai) remek dolog szerintem és meg kéne szüntetni az alaptalan félelmeket irányukban és inkább megtanítani a fejlesztőket a használatukra.

Tehát pl. van a 

feature-A

ág, amin többen dolgoznak. Szeretnék valamit implementálni. Ekkor ahelyett, hogy közvetlen a 

feature-A

ágba pakolnám a kommitjaimat lérehozom a feature-A-az-en-cuccaim-ne-pusholj-ide-legyszi-semmit-mert-rebase-zel-fogom-majd-par-szep-kommitba-osszerakni-a-sok-kis-kommitot-es-force-pusholom branchet. A kollégákkal megbeszéljük előre, hogy aki az -en-cuccaim-ne-pusholj-ide-legyszi-semmit-mert-rebase-zel-fogom-majd-par-szep-kommitba-osszerakni-a-sok-kis-kommitot-es-force-pusholom suffix-szal hoz létre egy ágat, azt nyugodtan force pusholhatja a tulaja, mások érthető okokból nem fognak pusholni oda semmit. Miután végeztem az implementációval, rebase-zel kiszépítem a múltat, majd pusholok a 

feature-A

ágba.

Közben teljesen nyugodtan lehet force pusholni a közös repóba, csak az a lényeg, hogy a megfelelő ágat használja az ember. Pár alapvető szabály betartásával könnyedén elkerülhetőek lennének a fenti esetek, és közben lehet használni a git legjobb képességeit is.

Alapvetően tévesnek tartom azt a szemlélet, hogy a git history márpedig szépen kell kinézzen. Nyilván jobb, ha szép, de elsősorban inkább igaz legyen. Ha nem sikerül csalás (értsd: history utólagos manipulációja) nélkül szépre csinálni, akkor inkább maradjon kicsit csúnya, de 100%-ban visszakövethető. Mert mindenekelőtt ezért tartjuk...
Thou shalt not lie

_______Peter
I am a stone. I do not move.

A history-t nem a publikált, éles brancheken írja újra az ember, hanem a feature-brancheken.

Ha elkezdesz implementálni egy feature-t egy új branchben, és tízszer kell átírnod az egészet, mert ahogy egysze többet tudsz a problémáról, egyre jobb megoldásokat adsz rá, akkor ennek az egész folyamatnak nem feltétlenül van helye a main historyban.

Pl. ha beolvasztás előtti code review-ra ki tudod tisztítani a history-t, azzal a reviewer dolgát nagyon-nagyon meg tudod könnyíteni.

Ha már egyszer a kód a mainline-ban van, akkor valóban nem írjuk át a history-t, és kész.

+1

A nyilvános repó-ra nagyjából igazak a fenti cikk ajánlásai, tehát ott ne írjuk át a history-t (ne "hazudjunk"), a sajátot pedig bizonyos esetekben átírhatjuk, mert nem "hazudunk" vele senkinek. Aztán a tisztítottat szépen felrakhatjuk.

Nagyon szépen le van írva ez az általam már korábban is megosztott "Getting solid at Git rebase vs. merge" cikkben.

Szerk.:
Nyilvános (feature) branch-ben is szükséges lehet a "hazudásra", de ott nagyon körültekintően kell eljárni, mert nagyon könnyen tönkretehetjük más munkáját. Kb. innen is indult az egész, hogy "push -f" -et nem körültekintően használták (hazudtak) és emiatt ment a levesbe bizonyos commit.
Tehát nyilvános repo-ba ne "hazudjunk" vagy nagyon körültekintően, minden érintett figyelmeztetésével!

Ha tízszer át kell írni, akkor tízszer át kell írni. De lehet, hogy lesz tizenegyedik, tizenkettedik és tizenharmadik átírás is két hónap múlva, még több tudással, amiket úgysem lehet utólag hozzászépíteni. Mi értelme letagadni a tökéletlen megoldásokat olyan állapotok "behazudásával", amik a valóságban soha nem léteztek? Ha tíz átírásban annyi szégyellnivaló belekerült, akkor lehet, hogy érdemesebb egy új branch-en újra implementálni az egész addigit a friss tudással, úgy talán a a kódban sem marad annyi szemét, nem csak a history-ban.

A reviewer pedig nyugodtan szenvedjen meg ugyanúgy az átírásokkal, hogy értse, hogy miért is az lett a végleges, ami. Vagy ha csak a végeredmény érdekli, akkor nézze csak a kezdő- és végállapot közötti diffet.

Részemről a history átírását csak lokálisan tartom elfogadhatónak. Pusholni már csak olyant tartok illendőnek, ami merge-ölhető a main history-ba. És nincs "ja bocs, azt hittem", meg "bocsi, rossz branch-en voltam", stb.

Végeredményben persze mindig a csapat fog dönteni a munkamenetről, ahhoz nyilván alkalmazkodom, de azért örülnék neki, ha minél kevesebb olyan fejlesztővel sodorna össze az élet, akik túlértékelik a history esztétikáját.

_______Peter
I am a stone. I do not move.

> A reviewer pedig nyugodtan szenvedjen meg ugyanúgy az átírásokkal, hogy értse, hogy miért is az lett a végleges, ami.

Ennek van amikor van értelme, van amikor nincs. Sokszor röviden le lehet írni, hogy miért a tizedik megoldás a jobb és miért nem az előző kilenc, sokkal rövidebben (időben is), mint végignézni és megérteni rengeteg kódot ami végül benne sem lesz a termékben.

> Vagy ha csak a végeredmény érdekli, akkor nézze csak a kezdő- és végállapot közötti diffet.

Egy nagyobb featuret kényelmesebb több commit-ban implementálni. A kezdő és végállapot közti diff sokszor sokkal nehezebben követhető, mint ugyanazok a változtatások 5-10-100 commitban.

> Részemről a history átírását csak lokálisan tartom elfogadhatónak. Pusholni már csak olyant tartok illendőnek, ami merge-ölhető a main history-ba. És nincs "ja bocs, azt hittem", meg "bocsi, rossz branch-en voltam", stb.

Igen, így értettem én is.

Minden eszközt lehet rosszul használni, ez nem az eszköz hibája.
A késsel is könnyedén megvághatod magad, ha nem tudod jól használni. A kanál sokkal biztonságosabb, de körülményesebb vele kenyeret vágni.
Minden verziókezelőnek vannak olyan funkciói, amivel törölheted a feltett anyagaidat.
A Git-et részletesen beállíthatod, hogy kinek mihez legyen joga. Ezt akár repository-nként is állíthatod, így lehet olyan repository, ahova csak megfelelő jogosultságú és tudású ember tehet fel, a fejlesztők nem is tesznek fel semmit, csak pull request-tel értesítik a megfelelő személyt, hogy tőlük le lehet kérni a módosítást, pl.: lásd itt.

>A késsel is könnyedén megvághatod magad

hupu körökben elterjedt magatartás a barom analógiák használata, amikor valami megmagyarázhatatlant akarnak megetetni a jobb sorsra érdemes vitapartnereikkel, lásd autós, ajtós-záras hasonlatok

>Minden verziókezelőnek vannak olyan funkciói, amivel törölheted a feltett anyagaidat.

Újabb bizonyíték arra, hogy a git homályban élő propagandistái nem ismerik a CVS-t (se)

" ugy hogy az a historybol is teljesen eltunjon."

Nem írtam azt, hogy a history-ból is eltűnik. cvs remove, svn delete
Git esetén se tűnt el a history-ból, pláne nem minden history-ból. Ezért is tudták visszaállítani.
Itt most két dolog keveredik:
1. A feltett módosításod felülírják. Ezt lehet sokféleképpen, akár egy sima commit-tal is, rossz merge-dzsel, ...
Én jól csináltam mindent, de valaki más belebarmolt. History(k) lapján (ha észrevesszük) visszaállítható a dolog.
2. History megváltoztatása. Erre valóban nem nyújt támogatást az SVN és CVS, de Git esetén sem az összes history változik. "A" felhasználó felrakja az Fe85... commitot, "B" felhasználó meg átírja D76f... commit-ra. "A" felhasználó history-jában ott van az általa felrakott commit, ami nem ugyanaz, mint amivel felülírta "B" felhasználó. Ha "A" felhasználó rakott fel hibásan valamit, akkor ez egy jó dolog, hogy "B" ki tudta javítani jóra. Ha "B" tudatlanságból használt egy olyan funkciót, amit nem tud, hogyan működik, akkor ez rossz eredményt ad.

A késes példa (példa az eszköz rossz használatára) nem tetszett mindenkinek, ezért álljon itt a shell rm parancsa. Eleve az rm (kés) nem biztonságos, mert törölni tud egy nem hozzáértő egy fájlt, amit a legtöbb fájlrendszernél nem is tud visszaállítani, sokkal biztonságosabb az ls parancs (kanál). Ráadásul az rm nem is hajlandó védett állományt törölni (hasonlóan, mint a push a Git-nél), de ráerőszakolhatjuk a -f flag-gel (hasonlóan, mint a Git-nél). Van aki szerint ez rossz, sokkal jobb, ha nem is lenne rm parancs, de ha van, akkor se legyen -f flag-je. Ezzel viszont azt a képességet vesztjük el, hogy rengeteg nekünk nem kellő védett fájlt nem tudunk hatékonyan törölni.
Mindenki eldönti mit tart biztonságosnak, hatékonynak és aszerint választ eszközt magának.

Sokan azt gondolják, hogy a git history átírása egyben azt is jelenti, hogy töröljük a régi history-t és felülírjuk az újjal és elvesznek dolgok. Azonban ez nem így van! A git megőriz minden információt és szükség esetén visszaállíthatók belőle a régi commit-ok.
Tehát a fenti példám az rm -f vs git push -f annyiban elvérzik, hogy míg az előbbi esetben (fájl rendszertől függően) tényleg elvesznek dolgok és nem állíthatók vissza, addig a git esetében megmaradnak a törölt elemek is, csak nem látszanak, és később visszaállíthatók.
Ha ilyen esettel szembesülünk, akkor használjuk a git reflog utasítást, amivel láthatóvá válnak a szükséges információk.
Egy-két példa a használatára.

Két gond lehet ezzel:
- A reflog opcionális, konfigban ki-be kapcsolható. "Normál" repókban alapértelmezetten be van kapcsolva, de bare repókban alapértelmezetten nincs. A userek pedig többnyire bare repókba pusholnak... szóval csak akkor lesz ott reflog, ha az admin körültekintő volt. Az itt olvasottak alapján én arra tippelnék, hogy a fenti konkrét esetben nem volt az :) Mindenesetre egy ideig még reflog nélkül, 

git fsck

-val is előhalászhatók a "törölt" dolgok, de az nehézkes.
- A userek többnyire szerveren lévő repókba pusholnak, ahova nem biztos, hogy van shell hozzáférésük, vagyis nem tudnak 

git reflog

-ot futtatni.

Ezek igazak, de a reflog a kliensek gépein alapértelmezetten be van kapcsolva és így a legtöbb kliensről visszaállíthatóak a régebbi commitok is. Egy kliensről biztosan, aki felrakta az eredeti commitot. A többi kliensről meg csak akkor, ha lekérték az eredeti commit felrakása utáni állapotot, de még az elrontás előttit.
Ez az egyik nagy jósága a gitnek, hogy nem csak egy helyen van meg a history, hanem rengeteg helyen.

ha körülöttem gitet használnak, akkor a saját dolgaimba egyszerűbb gittel integrálni a dolgaikat. gondolom. másik kettőt próbáltam évekkel ezelőtt, semmi olyan nem találtam ami nekem hiányzik a gitből, így nem használom őket, csak git. ha meg már van git, ráadásul megfelel, akkor minek váltsak?

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( sarkanyolo v | 2016. 12. 11., v – 15:28 )

A gitre szavaztam. Nem szeretem, de ez lett a standard.

( mileff | 2016. 12. 11., v – 23:30 )

Nem értem a mercurial miért ennyire nem népszerű. Gyakorlatilag ekvivalens a git-el. Szerintem az emberek főként csak a gitről hallanak, ezért szavaznak rá.

A hg kimondottan klassz (nekem csak egy hajszállal ugyan, de szimpatikusabb a gitnél). dolgoztam olyan helyen, ahol az volt a rendszerben, de, ahogy mások is írták, a kedvenc problémásabban definiálható, most gites környezetben dolgozok, tehát ha pár éve szavazok, akkor hg, most éppen git (lévén utóbbit használom állandó jelleggel éppen).

( lovas | 2016. 12. 13., k – 11:00 )

kimaradsz-lemaradsz, mertmindenkiezthasználja

( saxus | 2016. 12. 13., k – 13:19 )

Akkor most egy ellenvélemény következik:

/me egy elégedett svn user.

Hülye kérdéseket megelőzve:
- Igen, használok gitet is.
- Igen, tudom, hogy mennyivel faszább a git, mert a Linux is ebben van.
- Igen, tudom, hogy dvcs fapfapfap van.
- Igen, tudom, hogy a hg is létezik.
- Igen, tudom, hogy a fél világ gitet használ.

Miért használok még mindig svn-t (is)? Mert kicsi, egyszerű, teszi a dolgát és van, ahova bőségesen elég.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

10 évig voltam boldog SVN felhasználó. A tudatlanok könnyed boldogságában éltem és Total Commanderrel mergeltem a Subversion branch-ek között...
Imádkoztam update előtt, és mindig vigyáztam, nehogy butaságot commit-oljak.

Aztán elolvastam Joel Spolsky cikkét: Subversion-reeducation: http://hginit.com/00.html

Joel kurva jó író. Általában nagyra becsültem a cikkeit és megfogadtam a tanácsait.

Ezért esett rosszul, amit írt:

It turns out that if you’ve been using Subversion, your brain is a little bit, um, how can I say this politely? You’re brain damaged. No, that’s not polite. You need a little re-education. I walked around brain damaged for six months thinking that Mercurial was more complicated than Subversion, but that was only because I didn’t understand how it really worked, and once I did, it turns out—hey presto!—it’s really kind of simple.

Azt gondoltam, hogy Linus Torvalds egy arrogáns f@, amikor azt írja, hogy a subversion a legrosszabbul tervezett szoftver, amit ismer.
Pedig teljesen igaza van :-)

Toljátok végig Joel tutoriálját. Rengeteg kollegát láttam SVN-ről hg-re migrálni... Senki se nézett vissza.
Az Hg egyszerűbb, mint a rém komplikált SVN...
Én annyira radikális lettem, hogy nem szívesen dolgoznék olyannal együtt, aki még mindig svn-t használ. Olyan, mint a kétütemű motor. Fűnyíróba még jó.

"Egy dologban van talán az SVN-nek létjogosultsága, szvsz, ha bináris file-okat is kell tárolni."

TADA.WAV

Illetve hozhatnám még példának azt is, hogy és egy user van össz-vissz és soha nem is lesz több. Vagy amikor az egész dvcs jellege igazából csak plusz nyűg és lépés.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Vagy amikor az egész dvcs jellege igazából csak plusz nyűg és lépés.

Nem kötelező használni a dvcs jellegét, használhatod lokálisan, úgy, hogy nem publikálod sehová.

Egy felhasználó esetén is vannak előnyei. Csak egy pár:
- Kicsi, gyors.
- Könnyen kezelhetsz több különböző fejlesztési állapotot (Prod 1.0, RC 1.0, Dev 1.0, RC 2.0, ...)
- Könnyen kipróbálhatsz ötleteket, új branch, kipróbálod, ha jó felrakod valahová, akár csak egy részét, ha nem jó, akkor törlöd, mintha nem is lett volna.
- Egy-egy feature-t külön branch-ben fejleszthetsz, akár párhuzamosan is. Ha kész, akkor több verzióba is bepakolhatod.
- Egy-egy hibajavítást könnyű átrakni más verziókba is.
- Ha az egyszemélyes projekt több személyessé válik, akkor könnyű az átállás.
- Több egyszemélyes projekt könnyen együttműködhet.

Remek, de a legutolsó SVN repo még mindig az LDD fájljaim számára lett létrehozva, ott is leginkább azért, hogy ne 1drv-n kelljen oda-vissza másolgatni 3 gép között + legyen már róluk egy távoli backup.

Azok meg lényegében zipelt XML fájlok meg egy screenshot. Gyakorlatilag sima backupra használom és mind a feladat, mind fájlok jellegéből adódóan ezen soha senki nem fog egyszerre ketten dolgozni.

Másrészt munkahelyen is kb. 3-4 éve beszéljük, hogy át kellene rakni a meglévő projekteket gitre. Eddig mindig elhalt valahol az egész, egyszerűen azért, mert *minden* valós igényt lefedi jelenleg az svn és az egész migráció és az új workflow kialakítása csak egy plusz nyűg lenne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

persze

pl. modositas felkuldese repoba
svn ci -m "comment"
git add && git commit -m "comment" && git push (na jo ez nem 4-5 parancs hanem "csak" 3 :D)

van meg jopar ilyen, hasznalat kozben szokott folyamatosan eszembe jutni hogy "mennyire egyszeru lenne ez svn-ben"

a legdurvabb a merge-hell, amikor van valahol a patch-lista aljan egy conflict, es UGYANAZT a nyomorult file-t millioszor kell szerkeszteni mert az osszes felette levo patchet elQrja. mocskos idegesito amikor ugyanazt a file-.t szerkesztgeted, addolod, rebase --continue-zol fel oran keresztul. SVN-ben egy file egyszer conflictol, azt feloldod par masodperc alatt es kesz

Csak 2, a git add és a git commit összevonható: git commit -am "comment". Egyébként workflow függő, adott esetben előnyös, hogy a commit nem kerül azonnal fel az upstream repóba. Pl. én elgépelted a commit message-t, kihagytál egy fájlt a commitból, bennhagytál egy commentet a kódban, ilyesmit még lehet javítani.

Az utolsó bekezdésre: aki rebase-el az meg is érdemli. :)

"na jo ez nem 4-5 parancs hanem "csak" 3"

Sejtettem, hogy nem fog menni...
Egyébként ez is csak kettő lenne, git -am "comment", vagy ha sűrűn akarsz minden egyes commitot azonnal pusholni is, akkor beállíthatsz egy git vagy shell aliast, és már csak egy :)

"a legdurvabb a merge-hell, amikor van valahol a patch-lista aljan egy conflict, es UGYANAZT a nyomorult file-t millioszor kell szerkeszteni mert az osszes felette levo patchet elQrja. mocskos idegesito amikor ugyanazt a file-.t szerkesztgeted, addolod, rebase --continue-zol fel oran keresztul. SVN-ben egy file egyszer conflictol, azt feloldod par masodperc alatt es kesz"

svn-ben van már rebase? Vagy már megint svn-beli merge-elést akarod git rebase-hez hasonlítani, almát körtével? A git merge ugyanúgy csak egyszer fog conflictot jelezni.

Az továbbra sem a tool hibája, hogy rossz workflow-t alakítottatok ki magatoknak, és az se, hogy bár már rég felismertétek, még mindig nem változtattok rajta.

az -am-et nem ismertem, koszi a tippet
valami linket tudsz adni ra, hogy hogyan is mukodik/hasznalando? a git helpje gyakorlatilag maga a tomeny borzalom :-/

a rebase nem az en dontesem volt, egyebkent tokeletesen jellemzi a gitet hogy a felhasznaloi meg abban sem tudnak megegyezni hogy hogyan is kellene hasznalni
anno a profi 'gitmagusok' megbeszeltek hogy a rebase kevesbe szar mint a merge, ugyhogy ez lett...

a shell alias meg... basszus, ha sajat magamnak kell millio workaroundot csinalni egy toolhoz, az mar regen rossz (igen, egyebkent nalunk kb. mindenki egy elore osszerakott alias-csomagot hasznal, hogy ne kelljen kilometeres parancsokat gepelgetni egymas utan sorba, de ettol nem lesz jobb a tool)

Teljesen más filozófiával működik a két eszköz, sarkítva az svn és a git olyan, mint az SQL és a NoSQL... akkor van baj, ha valaki mindenáron az SQL-t vagy a NoSQL-t erőlteti, függetlenül attól, hogy mi a feladat. Ezt súlyosbítja, ha a git-et használja svn filozófiával vagy az svn-t git filozófiával.

"valami linket tudsz adni ra, hogy hogyan is mukodik/hasznalando?"

git commit -h azt írja, hogy:
-a, --all commit all changed files
És ebben minden benne van arról, hogy hogyan működik. A man page részletesebben (szájbarágósabban) mondja ugyanezt.

"egyebkent tokeletesen jellemzi a gitet hogy a felhasznaloi meg abban sem tudnak megegyezni hogy hogyan is kellene hasznalni"

Ezt már az előző HOVD szavazáson is elsütötted, és már akkor se volt semmi értelme.
A válasz ugyanaz, mint tavaly volt: Különböző csapatoknak és projekteknek különböző igényeik vannak, ezért különböző workflow-kat használnak. Nincs egy egyetemes workflow, ami mindenki igényeinek tökéletesen megfelel. Kifejezetten örvendetes, hogy végre van egy tool, ami többféle workflow kialakítását is lehetővé teszi, ahelyett, hogy az általa támogatott egyetlen workflow-t kényszerítene mindenkire, "eszi, nem eszi, nem kap mást" alapon.

"a shell alias meg... basszus, ha sajat magamnak kell millio workaroundot csinalni egy toolhoz, az mar regen rossz"

A fentebbi tapasztalatok alapján ezt a "millió"-t én "egy-kettő"-nek értelmezem ;), az meg bőven a tűréshatár alatt van.
Másrészt felmerül a gyanú, hogy nektek elsősorban a rossz workflow miatt kellenek a workaroundok.

A rebase jó, az egyik legfontosabb olyan feature, ami lehetővé teszi, hogy tényleg mi kezeljük a verziókat, ne csak belelapátoljuk a kódot egy központi megosztott backupba.
De a rebase-t lehet rosszul és rosszra használni.

Pusztán az itteni panaszaid alapján gyanús, hogy rosszul döntöttek.

"a shell alias meg... basszus"

Azert ez eleg kenyelmesen megoldhato.

"a legdurvabb a merge-hell" / "profi 'gitmagusok' megbeszeltek hogy a rebase kevesbe szar"

A rebase sokszor (legtobbszor?) jobb megoldas, mint a merge, bar annak is megvan boven a letjogosultsaga. Pl. git pull minek tolja tele a commit historyt merge commitokkal --rebase (vagy meg inkabb --rebase=preserve*) nelkul?

Van megoldas arra is, hogy ugyanazt a conflict-ot ne kelljen n-szer megoldani, azt meg aztan tenyleg egyszer kell csak beallitani es ugy hagyni.

*oke, a preserve debian jessie-n ugy tunik nem akarja valamiert az igazsagot nalam, a munkahelyemen viszont csak igy hasznalom. Igaz igy hosszu, arra viszont ott vannak a fent emlitett git alias-ok.

Nekem az a tapasztalatom, hogy ha nem értesz hozzá, akkor elbaszod...

...ha meg értesz hozzá, akkor a többiek által elbaszott merge eredményét javítgatod...

...ezért aztán az első néhány elbaszás után a nagy többség úgy használja, mint egy svn-t, de közben persze nagy az arca, mert látszólag git-et használ...

...és mivel csak látszólag használ git-et, néha elbízza magát, és lásd első bekezdés.

:)

Ha ennyivel többen használják

Több milliárd légy eszik sz*rt, szóval mégsem lehet olyan rossz a kaka, ugye?

Bocs, ez mindenkinek szól, aki isteníti a git-et. Sokáig SVN-t használtam (néha még most is), és teljesen rendben van, ahová nem kell dvcs. A tool-jai fantasztikusak, merge-elni is rettenetesen egyszerű vele (Eclipse alatt a CollabNet merge client, illetve a TortoiseMerge nagyon jók), stabil.

A git-ről viszont az a véleményem, hogy ezt commandline-os júzerek találták ki és készítették, akik az rsync és a tar összes kapcsolóját is fejből tudják. Nekem sajnos grafikus tool kell, mert sokszor igenis gyorsabban lehet dolgozni velük, és nem kell memorizálni mindent. Na ebben fos a git, akárhány GUI-t próbáltam hozzá, mindnek más a terminológiája, az azonos műveleteket másképp kell végrehajtani velük, és nem találtam olyan tool-t, ami rendesen működik Win-en és Linux-on is.
Mercurial párti vagyok, kb mindent tud, amit a git, csak sokkal egyszerűbben lehet megcsinálni benne, és a GUI-ja is nagyon kényelmes és jó. A learning curve-je is sokkal barátságosabb emiatt.

"Na ebben fos a git, akárhány GUI-t próbáltam hozzá, mindnek más a terminológiája, az azonos műveleteket másképp kell végrehajtani velük, és nem találtam olyan tool-t, ami rendesen működik Win-en és Linux-on is."

A beépítettet (git-gui) nem próbáltad? Az működik rendesen Linuxon és Windowson is, ugyanaz a terminológiája és ugyanúgy kell a műveleteket is végrehajtani.

( szegecs | 2016. 12. 21., sze – 17:18 )

Egyszerűen a git a legjobb VCS. Nekem különösen az tetszik hogy milyen jól van tesztelve:

$ git clone http://github.com/Xastir/Xastir
Cloning into 'Xastir'...
$ ls -ld Xastir
ls: Xastir: No such file or directory

Úgy értettem, hogy valószínűleg nem az lehet a gond, hogy nincs olvasási jog, hiszen ha minden rendben lezajlott, az olvasási jog hiánya esetén az ls -ld Xastir mutatja a kérdéses könyvtárat (legalábbis nálam egy-két próba alapján, FreeBSD, UFS).

Nem tudom, hogy hol lehet a kutya elásva, de bevallom, érdekel, mi (lehet) a hiba oka.

Gyanús nekem az az url; GitHub szerint a https://github.com/Xastir/Xastir.git vagy a git@github.com:Xastir/Xastir.git url-eket lehet a git clone-nak megadni. Gondolom a megadott címen nem talált git repót, ezért nem is klónozott le semmit. Viszont ezt közölnie kellene egy "fatal: repository 'http://github.com/Xastir/Xastir' not found" üzenettel.

Nem lövöm le a poént, hadd dolgozzon a manyeyeballs, nekem mint CVS usernek amúgy is tökmindegy. SSL környékén érdemes keresgélni (micsoda meglepetés, ki gondolta volna, trusted, secure, stb...)

Továbbá a git developpereket (a közhiedelemmel ellentétben nem torvaldosz) megkérdezni hogy miért jó elobfuszkálni egy segfaultot.

El lehet gondolkozni a nagy advokáció közben azon is, hogyan lehet megírva eme csodás exe, amikor ilyen dolgok meg tudnak benne történni - és még mi lehet a háttérben.

> +1, de azért ne abból induljunk ki amit te művelnél egy bugreportban az angol tudásoddal

Akkor innentől jön a személyeskedés? Gratulálok!

1. Egyébként azt magyarul is éppen olyan jól félreértettem volna.
2. Valóban nincs nagy magasságokban az angol tudásom, de ilyet nem is állítottam soha.

> Ugyan, ehhez nem kell külön erőfeszítés, megteszi az önmagának is, lásd fent

Én még nem láttam ennek semmi jelét, a kijelentéseden kívül, de nem zárom ki, hogy bizonyos körülmények között tényleg hibás. Kevés szoftvert ismerek, amiben nincs bug, egész pontosan nullát.