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
- 7473 megtekintés
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!
- A hozzászóláshoz be kell jelentkezni
++
---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!
- A hozzászóláshoz be kell jelentkezni
Rendben, nézzük meg, csak idő kell hozzá.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Hogyan kell a lokális repository változásait feltölteni egy távoli repóba?
--
CCC3
- A hozzászóláshoz be kell jelentkezni
git push
git push remote_nev
esetleg: git push --tags :)
- A hozzászóláshoz be kell jelentkezni
És hogyan lehet szabályozni a jogosultságot, mitől lesz nem readonly?
--
CCC3
- A hozzászóláshoz be kell jelentkezni
pl. van ssh hozzáférésed a géphez, amin van a repó.
Ekkor git clone git+ssh://gepnev/path/to/repo/
és menni fog a git push
ssh nélkül meg nem igazán biztonságos...
- A hozzászóláshoz be kell jelentkezni
Kösz, már nézem.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Https?
- A hozzászóláshoz be kell jelentkezni
milyen elonye van a gitnek az svnhez kepest?
- A hozzászóláshoz be kell jelentkezni
offline és a commitok könnyűszerrel kerülhetnek akár több repóba is. Számomra kényelmesebb is.
+ egyéb indokok :)
- A hozzászóláshoz be kell jelentkezni
hm, szoval semmivel :)
- A hozzászóláshoz be kell jelentkezni
Ehe (;
- A hozzászóláshoz be kell jelentkezni
Jobb a brach-ek kezelese.
- A hozzászóláshoz be kell jelentkezni
Pont ez az, amit nem használok belőle. Nekem inkább az tetszik, ahogy az objektumok tárolják a tartalmakat. Emiatt nem probléma, ha pl. egy részfát máshova mozgatunk. Ilyenkor az svn-nek meg kell magyarázni, hogy ezek a fájlok most azok.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
git for teh lulz
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
a g-push jó bármire is azon kívül, hogy lábon lövöd magad?
szerk.: ja, hogy nálat egy commit message tényleg annyiból áll, hogy "commit", esetleg "x"... Made my day, ahogy mondani szokás.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Nem érted. A lábonlövéshez vezető út az, hogy nem írsz tisztességes commit message-et.
Pedig azt még CVS-sel is lehet.
- A hozzászóláshoz be kell jelentkezni
+1
Szerintem még a rövid, egysoros megjegyzések sem elégségesek. A git-log úgy nem sokat mond, mellette kell minimum a git-log -p is... Ami naaaaagyon nem jó.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
valószínűleg
... nem olvastad a korábbi postokat, amikben egyszerű használatról volt szó
... a logikus érv nem mindenkinek elég, logika is kell a megértéséhez
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Minden bizonnyal nem érted, hogy egy verziókezelő rendszer mire való.
- A hozzászóláshoz be kell jelentkezni
ajanlom a tar nevu programot verziokezelesre
es bocsanat, hogy kommunikalni probaltam :)
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
Örülök neki, ha kommunikálni próbálsz:)
--
CCC3
- A hozzászóláshoz be kell jelentkezni
hat, remenykedtem egy hosszu tartalmas vitaban, de rovid uton elkuldtel a pics*ba :D
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
bizony, a flegma kulso erzo embert takar :-(
git-et nem, de a testverkejet hg urfit hasznalom
sot gitet is hasznaltam egy projecthez, de aztan rovid uton konvertaltam hg-ba, mert nem birtam tovabb
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Na tessék, már ezt sem. Hátha valamit mégis csak értek. Erre nem gondoltál:)
--
CCC3
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
A CCC projektben éppen annyi commit message van, amennyi szükséges. Más projektekben, más körülmények között más szabályok lehetnek hasznosak.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
ROTFL.
szerk.: Illetve nem is rotfl. Inkább fogadd őszinte részvétem.
- A hozzászóláshoz be kell jelentkezni
Köszönöm, de most nincs szükségem részvevőkre.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Tar formátumú CCC csomagok éppenséggel nincsenek, de van zip a windowsosokra tekintettel.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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 (;
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Respect a rendkívüli érdemeknek, de mégis kénytelen leszel elviselni, hogy vannak más vélemények.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Buta ember a saját kárán tanul, már az öregek is megmondták.
- A hozzászóláshoz be kell jelentkezni
Nyugtalannak látszol.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Talán ideje lenne szemészhez menned... (;
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni