Git(t)egylet? :)

Fórumok

Sziasztok!

Nagyon hype-olják mostanában ezt a git-et. Megnézegettem, és azt kell mondanom, hogy tényleg okos cucc. mrev, nem tudom, találkoztál-e már vele, de lehet, hogy érdemes lenne megfontolni a használatát. Gyakorlatilag semmi veszteség nem lenne a subversion-höz képest, viszont lehetne nyereség a közösségnek.
Én azt hiszem, azt fogom csinálni, hogy először a céges SVN repót átteszem Gitbe, és megnézem, hogy igaz-e, hogy ez egy szinte észrevétlen átállás. Ha igen, akkor átteszem a ccc-contrib repót is.
Esetleg van valakinek valami tapasztalata ezügyben?

w

Hozzászólások

engem majd erdekel az svn->git atallasrol a tapasztalatod

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hogyan kell a lokális repository változásait feltölteni egy távoli repóba?
--
CCC3

milyen elonye van a gitnek az svnhez kepest?

Nem megy a git push.

Részletesebben: Csináltam 3 külön gépen 3 darab git szervert, amennyire csak tudtam egyformára. Kettő jól működik, azonban a harmadikon (ahová az éles repositoryt akarnám rakni) ezt kapom:


+ git push --all
bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly

A kliens ugyanaz, csak a szerver nevét cserélem a scriptben. Természetesen a git-receive-pack benne van a path-ban, és a which megtalálja.

--
CCC3

Az volt a probléma, hogy git-push-nál az sshd indítja a git-es dolgokat (a bash-en keresztül), tehát az sshd-től örökölt PATH lesz érvényben, abban meg nincs benne a /usr/local/bin. A sshd-t nem akarom a távoli gépen piszkálni, úgyhogy 1-2 programot át kellett linkelni a /usr/bin-be. Így már megy.
--
CCC3

Van most egy kísérleti git szerver.

Így lehet letölteni a CCC2-t:
git-clone git://ccc.comfirm.hu/ccc2.git

És így a CCC3-at:
git-clone git://ccc.comfirm.hu/ccc3.git

A g-pull script hozza le frissítéseket. A szokásos módon lehet fordítani.
--
CCC3

git for teh lulz

--
Segmentation violation -- Core dumped blues

A git elég agyas dolog, úgyhogy kezdetben gond lehet, hogy a rengeteg funkcióból és parancsból mi az, amivel el lehet kezdeni a munkát. Ezért idetettem egy kis script gyűjteményt, amit a CCC repók karbantartásához használok. A gyakorlatban csak a g-commit, g-push, g-pull scripteket használom. Ezek persze nem pótolják a git dokumentációkat, de szerintem segítik a dolgok logikájának megértését.
--
CCC3

lol
--
CCC3

Bővebben:

A git nagyon jó. Baj viszont, hogy a kezdő (mint én) nem tudja, a git 745 parancsa közül melyik az, ami éppen kell. Ha rosszul kezdi el használni, akkor tényleg lábon lövi magát. Lábonlövésen az adatok összekeveredését, elvesztését értem. Nem értem bele a kommentek kihagyását. A felsorolt kb 10 (triviálisan egyszerű) script azért jó, mert látszik belőlük, mi az, ami az egyszerű használathoz kell.

A lábonlövéshez vezető gyors út, amikor a kezdő azzal találkozik, hogy a lokális és távoli repository inkonzisztens lesz. Ez általában természetes állapot, de rendbetételéhez a git igazi ismerete szükséges. A g-commit, g-push, g-pull scriptek elkerülik az inkonzisztens állapot kialakulását legalább abban az egyszerű esetben, amikor egyetlen fejlesztő egyetlen ágon dolgozik. Emellett, ha akarsz, kommentezhetsz.

Amúgy mindig is kezdő leszek, ui. havonként legfeljebb egyszer nézek a git-re, addigra pedig elfelejtem, amit korábban a doksiban láttam. Tehát kénytelen vagyok leegyszerűsíteni a dolgokat. Lábonlövés ellen.

A programokban 100 más módon meg lehet oldani a kommentezést. A komment a _program_ része, nem pedig az változatkezelő rendszeré. A programot kiveszem/beteszem a változatkezelőből, a komment vele jön.

Autóval meg kell állnod a piros lámpánál. A kézifékkel teszed-e? Nem, pedig az autóban van kézifék. Éppenséggel meg lehet vele állni, de van jobb megoldás.

Amúgy egysoros kommenteket szoktam írni a commitokba _is_. A scriptek ui. editálhatók. Nomost én a g-commit-ba beeiditálom az egysoros megjegyzést, a korábbi hasonló sort pedig (dátummal ellátva) kikommentezem. Ezzel maga a g-commit fájl is egy log. Ráadásul ez a log is benne van a változatkezelőben. Mindezt azonban csak akkor teszem, ha van érdemleges megjegyzés. Helyesírási hibák jávítását és efféléket megjegyzés nélkül commitolok.
--
CCC3

valoszinuleg meg...
...nem kerestel egy bizonyos valtoztast (bugfix, vagy eppen egy uj bug) egy program teljes historyjaban
...nem fordulhat elo veled az sem, hogy egy valtozas okat nem erted
...nem dolgozol olyan faban, amit tobb, mint szazan hasznalnak
...nem is jut eszedbe, hogy valaki szeretne reszeletesen kovetni a munkad valtozasait a kod olvasasa nelkul (lehet, hogy nem is ert a programozashoz!)

ps.: az autos hasonlat a logikus erv potszere :)

--
When in doubt, use brute force.

Hát az már igazán nem az ő hibája, hogy a saját hasonlatodat sem érted (;

Te hogyan parkolsz le egy autót? Én megállok, behúzom a kéziféket, és megyek a dolgomra. Te mindig viszel magaddal valakit, aki megy ügyintézni, amíg te ott maradsz a kocsiban, és taposod a féket, hogy a kocsi el ne guruljon? Vagy ő marad a kocsiban taposni, és te mész dolgot intézni? Esetleg egy féltéglát rendszeresítettél ilyen esetekre, és azt teszed a fékpedálra?

A kódban lévő kommentek és a commit message más célokat szolgálnak. Egyik sem helyettesíti a másikat.

De, gondoltam. És arra jutottam, hogy a topikban linkelt három git repository, és az ebben a szálban mutatott performance-od alapján, hogyha van is valami, amihez értesz, annak nincs köze a verziókezeléshez.

Esetleg vethetsz néhány pillantást a Documentation/SubmittingPatches file-ra is, hátha tesz említést commit message-ekről is...

Meg fogsz lepodni, en se mindig irok kommit uzenetet egyszeru javitgatasokhoz (pontosvesszo, :retab, debug uzenetek kivetele, stb.). Az ilyenek ugyanis a diffbol ranezesre is kiderulnek, nem kell ehhez komment. Nyilvan a nagyobb valtozasokat en is kommentelem, es ezt mrev is kiemelte.

Amugy pedig erre inkabb a ChangeLog valo, amit a kommitolas elott frissit az ember. Mivel datumra vissza lehet benne nezni, hogy mikor milyen bugfixek voltak, a verziokezelo kommentjei nem annyira fontosak. Raadasul ez nem vesz el, ha hirtelen ugy dontok, verziokezelot valtok, es nem akarok szopni az importtal.

Persze lehet flame-t inditani, hogy ki mit szeret, de azert en belegondolnek abba, hogy masnak masok lehetnek a szokasai. Lehet hogy a tied egy jo szokas, de nem biztos, hogy az egyeduli ut az udvozuleshez.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Meg fogsz lepodni, en se mindig irok kommit uzenetet egyszeru javitgatasokhoz (pontosvesszo, :retab, debug uzenetek kivetele, stb.). Az ilyenek ugyanis a diffbol ranezesre is kiderulnek, nem kell ehhez komment."

A commit message lényege, hogy a diff megnézése _nélkül_ is látni lehessen, hogy mi változott, és miért változott.

"Amugy pedig erre inkabb a ChangeLog valo, amit a kommitolas elott frissit az ember. Mivel datumra vissza lehet benne nezni, hogy mikor milyen bugfixek voltak, a verziokezelo kommentjei nem annyira fontosak."

'git show' vagy 'git log -p' egyben kiírja a commit message-et és a hozzá tartozó változásokat. Ez elég nehézkesen kivitelezhetőnek tűnik a ChangeLog-os, dátum alapján visszakeresős módszerrel.
Ezenkívül a repository böngésző toolok (gitk, hgk) a commit message-eket jelenítik meg, nem a ChangeLog tartalmát.

"Raadasul ez nem vesz el, ha hirtelen ugy dontok, verziokezelot valtok, es nem akarok szopni az importtal."

Egyrészt attól, hogy verziókezelőt váltasz, a commit message-ek nem vesznek el, mert a régi repository még megmarad.
Másrészt, bár a ChangeLog maga nem veszik el, az égvilágon semmit nem érsz vele, ugyanis megfelelő import hiányában nem tudod egymáshoz kapcsolni az egyes kommenteket és a hozzá tartozó változásokat.

"Persze lehet flame-t inditani, hogy ki mit szeret, de azert en belegondolnek abba, hogy masnak masok lehetnek a szokasai. Lehet hogy a tied egy jo szokas, de nem biztos, hogy az egyeduli ut az udvozuleshez."

Tanulhatsz mások tapasztalataiból, vagy várhatsz is akár, amíg megtanulod a magad kárán. Utóbbi fájdalmasabb, saját tapasztalat (;

1) Mivel a szintaktikai valtoztatas meg csak nem is minor problema, szerintem nincs szukseg akkora csinnadrattara korulotte, mintha egy segfaultnak talalja meg az ember az okat.

2) a: Magadnak mondasz ellent, nem arrol van szo, hogy a commit msg tartalmabol kitunjon a valtozas anelkul, hogy barmit latnank a diffbol? Ez datum/ido alapjan visszakeresheto a ChangeLog-bol is.
b: Persze, hogy persze. A repo bongeszo toolok erre valok, es nem ChangeLog nezesre. Arra mas programok valok.

3) Ha nem importalom, az uj verziokezelo alatti repo mar nem fogja hordozni a regi commit msg-ket, barmit is mondj. A ChangeLog pedig verziokezelotol fuggetlen hordozza a valtozasokat.

4) Nem mondtam, hogy az en modszeremnek nincsenek hibai - de az en projektjeimhez es 'fejlesztesi modell'-emhez tokeletesen megfelel. De en nem is allitom, hogy az en modszerem udvozito megoldas.
Nezd, mindenkinek masok az igenyei, a szokasai. Ugyanugy, ahogy nincs ket egyforma program, nincs ket egyforma fejleszto sem. Lehet jotanacsokat adni, de azt mar a delikvensre kell bizni, hogy eldontse: mennyire hasznosak neki az adott tanacsok. Nem ismersz sem engem, sem a projektjeimet annyira, hogy velemenyt nyilvanithass arrol, hogy ez nekem mennyire karos, es mennyire nem az. Amennyire tudom, a cel valaszt eszkozt, es nem forditva. Ugy gondolom, vagyok annyira tapasztalt (hobbi)koder, hogy ki tudjam valasztani, mely eszkozok felelnek meg a celjaimhoz, es melyek nem.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nos.

"1) Mivel a szintaktikai valtoztatas meg csak nem is minor problema, szerintem nincs szukseg akkora csinnadrattara korulotte, mintha egy segfaultnak talalja meg az ember az okat."

Ebben egyetértünk.
De te azt mondod, hogy egyszerű javításokhoz nem mindig írsz commit message-et. Pedig egy "kivettem az ottfelejtett debug printf()-et" vagy "indentation fix" szintű dolog olyankor is kellene.

"2) a: Magadnak mondasz ellent, nem arrol van szo, hogy a commit msg tartalmabol kitunjon a valtozas anelkul, hogy barmit latnank a diffbol?"

Nincs semmiféle ellentmondás, különböző use case-ek vannak.
Van amikor csak a logot, mitöbb, shortlogot nézi az ember (pl. lássuk, mit csináltak a kollégák a múlt héten), és van, amikor a commit message-et és a hozzá tartozó változásokat együtt (pl. commit X regressziót okoz, javítani kellene; ilyenkor különösen hasznos bír lenni, ha a "miért" is ott van a commit message-ben).

"Ez datum/ido alapjan visszakeresheto a ChangeLog-bol is."

Hja, visszakereshető, de mekkora overheaddel?

"A repo bongeszo toolok erre valok, es nem ChangeLog nezesre."

Hülyeség. Egyrészt megjeleníthető commit message-ek hiányában a repo böngésző tool semmit nem ér, másrészt a commit message a repo-beli history alapvető része.

"Arra mas programok valok."

Mintpéldául? Különösen olyan érdekelne, ami gitk/hgk-hoz (vagy akár git show vagy log -p-hez) hasonló egyszerűséggel egymáshoz rendeli és megmutatja a ChangeLog-beli megjegyzést a hozzá tartozó diff-fel.

Btw, ChangeLog-gal hogyan kezelsz egyszerűen branch-eket és merge-eket?

"3) Ha nem importalom, az uj verziokezelo alatti repo mar nem fogja hordozni a regi commit msg-ket, barmit is mondj."

Semmi ilyesmit nem mondtam.

"A ChangeLog pedig verziokezelotol fuggetlen hordozza a valtozasokat."

Csak az üzeneteket, amiket beleírsz. De hogy egy adott üzenethez milyen változások tartoznak (értsd: a diff), azt nem. Innentől pedig a ChangeLog gyakorlati értéke nulla.

"Nezd, mindenkinek masok az igenyei, a szokasai. Ugyanugy, ahogy nincs ket egyforma program, nincs ket egyforma fejleszto sem. Lehet jotanacsokat adni, de azt mar a delikvensre kell bizni, hogy eldontse: mennyire hasznosak neki az adott tanacsok. Nem ismersz sem engem, sem a projektjeimet annyira, hogy velemenyt nyilvanithass arrol, hogy ez nekem mennyire karos, es mennyire nem az. Amennyire tudom, a cel valaszt eszkozt, es nem forditva. Ugy gondolom, vagyok annyira tapasztalt (hobbi)koder, hogy ki tudjam valasztani, mely eszkozok felelnek meg a celjaimhoz, es melyek nem."

Jópár kis egyszemélyes, kisebb-nagyobb, illetve több országbeli kutatóintézeteket összefogó projektben való (nem hobbi) kóderkedés, számos SCM migrálás, néhány, az RCS írójának kezei alatt eltöltött év, valamint a kelleténél több szívás során azt tapasztaltam, hogy vannak tipikus verziókezeléssel kapcsolatos hibák, amik az adott projekttől (nagyság, résztvevők száma és kultúrája, alkalmazott SCM) teljesen függetlenek. Ezek között előkelő helyen vannak a felületesen (mitöbb, egyáltalán nem) megírt commit message-ek.
Természetesen továbbra is kötheted az ebet a karóhoz, és pisálhatsz széllel szemben, de majd ne csodálkozz, ha olyan lesz a nadrágod.

Persze, hogy vannak. És némelyik hibás. Felesleges az igazi verziókövető, ha nem tudod, hogy melyik állapot mit takar, egy sima changelog mellett elegendő a tar is, mint verziókövető cucc (újabb verzió kiadásakor újabb archívum). Ebből is látszik, hogy a kettő "verzió" egészen mást jelent. Egy-egy újabb tar.gz/tar.bz2 fájl kiadásához több kisebb lépésen keresztül vezet az út, a kisebbek vannak valamilyen RCS-ben, esetleg párhuzamosan több ágban is, stb. Ahogy itt elnézem, a fogalmak jócskán keverednek egyes embereknél. Bocs, ha kicsit összecsapott a hozzászólásom, így sikerült.

Van egy elképzelésed, mire való a verziókezelő, és nem gondolsz arra, hogy másra, másképp is lehet használni. Pl. ahogy olvasom, kezdetben a Linux kernel verziói is tarokban voltak, és emailben küldött patchekkel dolgoztak. Namost, ha ezeknek a kezelését a git automatizálja, az hasznos dolog, függetlenül attól, hogy az "igazi" verziókezelésben még mi minden van ezen felül. Lassú modemes kapcsolattal nehéz tarokat mozgatni, amikor az svn/git még prímán működik (erre nekem szükségem van nyáron). A fejlesztésében nem használjuk az svn/git-et, csak a _közreadásában_. A kliens az svn up vagy g-pull parancs + install után a legfrissebb/legtökéletesebb verzióhoz jut. Megjegyzem itt, hogy nincsenek bináris CCC csomagok, hanem minden platformon (Linux,Solaris,BSD,Windows) helyben fordítunk, és frissítéskor is fordítunk. Az svn/git tartalmazza a projekt múltját, ami ugyan nem mindenkinek kell, de nem is zavar. A helyben fordítástól eltekintve ez ugyanolyan használat, mint az Ubuntu frissítései. Nem gondolnám róla, hogy felesleges.
--
CCC3

Kb. egy évig használtam git-et svn mellett. Főleg topic branchek, néha otthoni munka volt a feladat, amit a git jobban megoldott. Ez a leírás sokat segített. Az első pár nap döcögősre sikerült, de végül megérte.
Valaki kérdezte miért jobb a git?.
Ezek pedig hasznos videók.
Saját tapasztalatom alapján kicsit nehéz a betanulás, bár amennyire emlékszem a CVS-el is így voltam 7-8 éve. Ettől eltekintve az általam próbáltak közül (CVS, svn, mercurial, git) a git messze a legjobb.

Kérdezték, miben jobb a git az svn-nél. Egy válasz: jobban kezeli a branch-eket. Talán igen, de engem ez nem érint, mert nem használok brancheket. Ami szvsz igazán számít, hogy az elgondolás, amin a git alapul sokkal jobb. Erről írok egy kicsit.

Az svn _fájlok_ változásait követi nyomon. Ahhoz, hogy elkezdje figyelni egy fájl változásait, szólni kell neki, hogy itt van egy új fájl. Ha a fájl _neve_ megváltozik, szólni kell neki, hogy változott (különben nem tudja, hogy korábban is létezett, csak más néven). A fejlesztés során nem ritka, hogy átszervezések történnek, pl. directory struktúrák máshová kerülnek (átneveződnek). Ilyenkor munkás megmagyarázni az svn-nek, hogy melyik fájl, hol folytatja a pályafutását. Szerintem ez akadályozza a munkát, nem szeretem.

A git un. objektumokban tárolja a _tartalmat_. A blob objectekben fájlok tartalmát, a tree objectekben directoryk tartalmát. Minden objektum tömörítve van, és minden objektum neve egyenlő a tartalmának SHA1 kódjával. Azaz két objektum neve aa. egyenlő, ha a tartalmuk egyenlő. Nomost ennek mindenféle követkeménye van, itt csak egyet nézek, egy fájl átnevezésének esetét.

Ha egy fájlt átneveznek (bárhová átmozgatnak), attól a fájl _tartalma_ nem változik meg, és ezért a fájlt tartalmazó blob object (és annak neve sem) változik. Változnak viszont a directory struktúrák, és az azokat tartalmazó tree objectek. Az objectek változásainak nyilvántartását viszont típusuktól függetlenül ugyanaz a mechanizmus végzi (ami más most nem témánk). A tanulság, hogy a git alapelgondolásából adódóan az átnevezett fájlok nyomonkövetése sokkal egyszerűbb. Ezt szeretem a git-ben. Amiről itt irkálok, az a Git User's Manual 7. fejezetében (Git concepts) van részletesen leírva.
--
CCC3