[Frissítve] Leállt a GitHub

Programozás

GitHub offline

20 perccel ezelőtt leállt a GitHub. Jelenleg megpróbálják helyrekalapálni egy "vészhelyzeti karbantartás" (jelentsen az bármit is) keretében..

[ status.github.com | @githubstatus ]

Frissítés: 12:20 UTC Everything operating normally.

( kmARC v | 2015. 05. 06., sze – 14:01 )

20 perceeee?!

Délelőtt sem értem már el. Pont hétvégén beszélgettem a menedzseremmel erről, hogy mennyire github-orienteddé vált a fél világ, leginkább a webes devek (bower github nélkül nem is megy kb.), szóval mi lenne, ha egyszercsak leállna :-)

( nevergone v | 2015. 05. 06., sze – 14:22 )

Na ezért (is) érdemes elosztott verziókezelő rendszert használni.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

en hasznalok SVN-t (sajat projectekre) es gitet (ceges melo) is
mult heten felraktam egy SVN servert a fejlesztoi gepre, amibe idonkent letukrozom az aktualis gites allapotot, mert tele lett a tokom az eltunedezo patchekkel :D

En szeretem az svn-t tobb okbol is. Igaz hogy nem lehet vele olyan vagany, fancy patch-tologatasokat csinalni mint gitben, de amit beleraksz az legalabb ott van, es sokkal egyszerubb, kenyelmesebb a mindennapi hasznalat (svn ci vs git add + git commit + git push)

„de amit beleraksz az legalabb ott van, es sokkal egyszerubb, kenyelmesebb a mindennapi hasznalat (svn ci vs git add + git commit + git push)”

Ha annyira fontos, akkor készíthetsz aliast a "git add; git commit; git push" parancsokra. De nyilván mindenki azt használja, ami kézre áll.

Ui.: Van "git commit -a" is.

Ui. 2.0: Ez az „egyszerűbb”, „kényelmesebb” nekem mindig fura. Én Git-et használok parancssorból mindenféle tool nélkül. Van néhány aliasom, hogy ne kelljen annyit gépelni (pl. "git cia" -> "git commit -a", "git ciam" -> "git commit --amend"), évek óta azokat használom és annyi. Szerintem ha valaki a 8-10 alapparancsot megismerni, már teljesen jó Git felhasználó. És azoknál sem kell minden argumentum, sőt.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

> egyszerubb, kenyelmesebb a mindennapi hasznalat
Aha, aztán amikor van egy regressziód, valahol kb. 40 committal ezelőtt jött be, akkor te állsz bambán, a világ fejlett része meggit [code]bisect[code]el.

Ugyanez akkor, amikor egy-két branchet >10 committal merge-ölnöd rebase-elned kellene, de hát inkább vért pisálsz az svn-edben ahelyett, hogy pár perc alatt végeznél. Végülis, ha időre kapod a fizetést, nem teljesítményre...

sosem pisaltam meg vert svn-ben merge-nel
gitnel mar tartott fel napig (nem nekem, hanem a gitet fanatikusan imado es jol ismero kolleganak) egy branch rendberakasa :D

a rebase-eknel ott tudnam falhoz baszni az egeszet mikor mar hatodszor dobja elem ugyanazt a file-t egy hatodik patch miatti conflicttal...

persze aki idore kapja a fizetest, nem teljesitmenyre az biztos szivesen csesz el orakat a git patchek tologatasara :)

Ez a rebase fura dolog. Egyrészt túl van misztifikálva, pedig ha normálisan commitol az ember (nem kerül egy commitba 300 sor módosítás 10 helyen szétszórva), akkor nincs vele gond. Másrészt pedig nem kötelező használni, ez is csak egy eszköz. Vannak olyan saját projektjeim, ahol csak elvétve rebase-elek és olyan fejlesztésekben is részt veszek, ahol kifejezetten tilos rebase-elni.
Néha tartottam Git oktatást fejlesztőknek, nem is mondtam el a rebase-t, csak ha kifejezetten kérték. A kezdőket csak összezavarja, a haladók pedig úgyis megismerik. Max. nem lesz „egyenes” a branch, de amúgy meg általában ez nem is szempont. Csak működjön és könnyen, gyorsan tudja használni a fejlesztő.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

igen, erdekes hogy a git-userek sem tudnak megegyezni abban hogy hogyan is kene/lenne jo hasznalni :)
nalunk a fetch/rebase a policy, alapvetoen azert mert a rutinos git-magusok ezt javasoltak (nyilvan meg is indokolva)

amugy nekem pl. tetszik a rebase (sot, az egesz git) 'filozofiaja', nekem a gyakorlati mukodessel van bajom, ott is leginkabb a conflictokkal, amiknek a feloldasa svn-ben SOKKAL gyorsabb volt, gitben meg lassu, maceras, szopatos :(

az utobbi fel evben tobb idot toltottem a gites 'adminisztracioval' mint elotte svn-nel hat even at...

Nincs egyértelmű használata a Gitnek, pont ezért jó: az adott helyzethez lehet igazítani. Talán ezért is olyan „svájcibicskás”.
Tapasztalataim szerint a problémákat gyakran nem Git/SVN, vagy más okozza, hanem a verziókezeléssel kapcsolatos általános ismeretek hiánya. Pl. dolgoztam együtt Java fejlesztőkkel, akik SVN-t használtak végig egy ággal és a munkanap végén commitoltak egyet. Ennyi volt a verziókezelési tapasztalatuk is. Valószínűleg ott sem ment át a lényeg.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ha szep history-t szeretnek, akkor csinalok egy vadi uj branch-et, cherry-pick-kel atrendezem a kommitokat, ahogy nekem tetszik, rebase-el egyesitem a szomszedos kommitokat, ha kell, amikor kesz van, akkor publikalom.

Az eredetit (amibol kiindultam) pedig rebase-elem erre a branchre (meg mielott kommitot egyesitettem volna!), majd miutan kommitokat egyesitettem, akkor ujra.

Ebbol kovetkezik, hogy altalaban minden apro kis szar modositast kommitolok, mert "ugyis egyesiteni fogom".
Valamelyikbe mar ugyis irom a kommit szoveget, hogy to_squash, aztan ujsorba a tenyleges szoveget.

Mert rebase-ben kicsit el tudja teveszteni az ember, hogy most melyik fog melyikbe lapulni...
De ha eleve benne van a kommitba, hogy to_squash az elozobe, akkor tudom, hogy azt kell rebase -i nel 's'-be tenni... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez jó ötlet, köszi!
Mondjuk én ritkán vonok össze commitokat, mert nem zavar, ha több van, amennyiben azok logikai egységet képeznek.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Igen, használom a rebase-t, mert gyakran szoktam pusholás előtt régebbi commitokat kijavítani, ha valami kimaradna belőle. Csak az összevonás áll távol tőlem, de van létjogosultsága. Én szívfájdalom nélkül elcommitolok 2 soros módosítást is, ha egységet alkot. Aztán úgy hagyom. Volt olyan párszor, hogy a commit üzenet hosszabb volt, mint a patch. :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

hat annyi, hogy 's'-be teszed, amit lapitani akarsz az eggyel regebbi kommitba.
A zavaro az, hogy fejjel lefele van a lista a 'git rebase -i'-nel, igy mindig rosszal egyesitettem a kommitot.

Azota eleve beleirom a kommitba, hogy to_squash, mert amikor egyesitem, akkor meg kikommentelem azt a sort, es senki se veszi eszre... :)
(amelyik kommitba meg to_squash van, ott rebase-nal rogton irom is at 's'-re a sor elejen)

Igy egy feature-t van ugy, hogy 20 kommittal csinalok meg, a vegen meg igazabol 1-2 kommittal tolom fel a repoba. Igy nem latjak a "benazasomat".

Egyebkent meg itt egy tok jo iras:
http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmf…

> Volt olyan párszor, hogy a commit üzenet hosszabb volt, mint a patch. :)

Stackoverflow linkek? :) Github meg piszok modon ossze is koti...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Ebbol kovetkezik, hogy altalaban minden apro kis szar modositast kommitolok, mert "ugyis egyesiteni fogom".
Valamelyikbe mar ugyis irom a kommit szoveget, hogy to_squash, aztan ujsorba a tenyleges szoveget.

Mert rebase-ben kicsit el tudja teveszteni az ember, hogy most melyik fog melyikbe lapulni...
De ha eleve benne van a kommitba, hogy to_squash az elozobe, akkor tudom, hogy azt kell rebase -i nel 's'-be tenni... :)" 

git commit --squash HEAD^
git rebase -i --autosquash

Esetleg ha nagyon magabiztos vagy, akkor 

git config rebase.autosquash true

, de én nem lennék.

HTH ;)

Igen, csak el kellene jutnod addig, hogy ezek lehetőségek és nem kötelező szabályok. Nem akarod használni, nem kell. De legalább van rá lehetőség.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

"SVN erre milyen eszközt is ad...?"
olyat, hogy EGYSZER kell az adott file conflictjait feloldnom, nem egymas utan hatszor aztan nyomkodni a "git add/git rebase --continue' parost :)

Bisect nincs svn-ben, szoval nincs mit mivel osszehasonlitani. Ha visszaolvasol lathatod hogy a gittel nem az a problemam hogy keves feature-e lenne (sot, kimondottan jo dolgokat tud amik komoly elonyt adnak az svn-hez kepest) hanem hogy rengeteg idot elvisz es nagyon maceras/kenyelmetlen a hasznalata

"Ismerd meg mindkettőt, majd alkosd meg a véleményed."
SOKKAL tobb idot toltottem mar a git megismeresevel mint az svn megismeresevel, es meg mindig sokkal tobb vele a problemam, sokkal tobb ido megy el az adminisztraciora, stb

SVN-be felesleges is lenne a bisect.

A bisect előnyei akkor jönnek elő, hogyha a history rendezett, egy commit csak egy, jól leírt logikai változtatást tartalmaz. Egy verziókezelő alapvető feladatai közé tartozik a user abbéli támogatása, hogy ezt kényelmesen és könnyedén meg tudja tenni. Ami ebben nem nyújt segítséget, az gyakorlatilag aktívan hátráltat.
Volt már olyan, hogy egy team nagyrészt a lelkes bisectelésnek köszönhetően kb. tizedére tudta rövidíteni az átlagos bugreport-to-fix átfutási időt, ami aztán az évvégi bónuszra is jó hatással volt, szóval az ilyen history érték, ráadásul nem csak a bisectelhetőség miatt.

"SVN erre milyen eszközt is ad...?"
olyat, hogy EGYSZER kell az adott file conflictjait feloldnom, nem egymas utan hatszor aztan nyomkodni a "git add/git rebase --continue' parost :)

Szerencsére nem kell egynél többször megoldani a merge conflictot. A megoldás: git-rerere http://git-scm.com/docs/git-rerere A gitet pont arra tervezték, hogy nagyon sok egymással párhuzamosan futó ágat tudjon kényelmesen kezelni, egy ilyen alap funkciót természetes, hogy tud.

A rerere nagyszerű találmány, de csak akkor segít, hogyha ugyanaz a conflict fordul elő újra és újra, pl. feature branch-ekből rendszeresen újraépített integrációs branch. Kolléga fentebb említette, hogy náluk fetch-rebase a policy van, ki tudja miért, ott pedig rendszerint nem jönnek elő ugyanazok a conflict-ok.

Ha már kényelemnél tartunk, akkor a mindennapi rutinfeladatokat nem a kedvenc szerkesztődben kellene elvégezni 1-1 gyorsgombbal? Nálam pl. Sublime Text + Sublime Git esetén: van egy külön git status szerű tab, ahol shift + c-vel lehet commit -a-t csinálni, illetve a git push-t hozzárendeltem a sosem használt pause gombra (ctrl + pause lett a git pull). A kommit és push összesen 3 gomb lenyomását igényli, lehet ennél egyszerűbb?

Az hogy az egész fájlt hozzáadja. A szoftverfejlesztés érdekes egy állatfaj. Átírod a kódot, de előfordul, hogy nemcsak annyit módosítasz, amennyi egy feature/bugfix/etc. commitba "belefér". Márpedig a commitodat szereted konzisztensen tartani, mert goodpractice cherrypickre, rebase-re, merge-re felkeszíteni.

Onnan tudod, hogy valami nem stimmel, ha svn-es mintára kizárólag fájlokat adsz hozzá a commithoz. A git alapegysége a commit, nem a fájl.

Persze ha annyira penge valaki hogy csak commitolható módosítást csinál, vagy a projekt tényleg a pársoros bugfixek státuszában van, akkor jól tud jönni. Egyéb esetben letörném a kezét annak, aki ész nélkül rá sem néz a stage előtt arra, mit is stage-el. Tessék megnyitni a git guit vagy tiget, és megnézni, hogy az adott hunk biztosan beletartozik-e.

Az a gond, ogy sokan svn-ből jönnek gitezni és vagy nagyképűen fallbackelnek svn-re, mert fel sem fogják, a git hogy működik, vagy pedig tovább abuzálják a gitet anélkül, hogy egy köyvet elolvasnának róla.

Oké, ez igaz, de ki lehet védeni úgy, hogy módosítok egy logikai egységnyit és elcommitolom. Egyben. Egy kezdőnek sokkal jobb ez, mint patch-eket vadászgatni, aki haladóbb, az pedig úgyis "git add -p"-vel tolja.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Itt kezdőkről van szó, ilyenkor még az sem okoz tragédiát, ha véletlenül egy-egy commitba kicsit több minden kerül bele. A lényeg, hogy kellően alacsony legyen a belépési küszöb, tisztába legyenek az alapvető eszközökkel és azokat bátran és gyorsan tudják használni a mindennapi munkájuk során. Aztán később lehet egyre haladóbb dolgokat megismerni, amikor a kezdeti nehézségeken átlendültek.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez veszélyes terep. Szerintem attól, hogy valaki kezdő, nem szabad direkt belérögzíteni a rossz practice-t... Ez olyan, mintha egy ruby-on-rails-be* belecsöppenő fejlesztőnek azt tanácsolnád, hogy továbbra is php-módra kókányolja a html-be a ruby kódot mindenféle MVC-szerű dolog nélkül, mert az könnyebb.

*: nem rubyztam, nem tudom, erre van-e egyáltalán lehetőség.

> hogy úgysem egy logikai egységnyit változtatsz egyszerre :-)

Biztos en csinalom nagyon fapadosan, de ha nem egy fajlban van a tobb logikai egyseg az egyszeru, mert egymas utan tobb kommitba beteszed.
Ha egy fajlban tobb dolgot is megcsinalt az ember es utana kommitolja, akkor en ugy szoktam, hogy csinalok a fajlon egy
1. cp valami.c valami_uj.c
2. valami.c-ben csak egy logikai egyseghez tartozot hagyok meg, a tobbit meg revertelem.
3. kommitolom a valami.c-t.
4. mv valami_uj.c valami.c
5. kommitolom a masodik logikai egyseget.

Kicsit macera, meg odafigyelest igenyel, de jobb, mint utolag szetszedni egy kommitot 2 reszbe.
Foleg ha az ember mar pusholta, mert akkor a rebase elvileg tiltott gyumolcs.
(akkor mar csak ugy lehet, hoyg uj lokalis branch, szetszed a kommit, pusholja az ember lesz egy vadi uj branch-be, a regit meg torli)

De abszolut kezdo vagyok git teren, szoval csak ovatosan a tanacsaimmal:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A fent vázolt, ide mozgatom, oda mozgatom, stb. dolog kényelmesebb, mint ha a git sorba listázza neked a fájlban a változtatásokat, s eldöntöd, hogy igen, mehet bele, vagy a következőbe majd csak?

Hááát, én nem csinálok ilyet rendszeresen, elismerem, de így látatlanba semmilyen diff app nem kényelmesebb. De leginkább a kézzel való ide-mozgat -- oda-mozgat játszadozástól mennék a falnak.
--
blogom

ha mar egereszni kell akkor megette a fene az egeszet :D
amugy erdekelne hogy a 15 modositott file-t hogy addolod hozza egy gombnyomassal ugy hogy csak az keruljon be a commitba amit tenyleg akarsz, akar egy file-on belul bizonyos reszeket hozzaadva masokat nem (ha mar gitnel tartunk)

a hotkey-hozzarendeles erdekes otlet, tetszik!
bar nalam a kb. 10-12 repoval nem biztos hogy tul egyszeru lenne :D

„max. annyi elonyt ad mondjuk egy svn-hez kepest, hogy lokalisan tudsz kommitolni”

Meg branch-eket kezelni, és mindent a clone/pull és push kivételével. Szóval mindent, amire feltétlenül szükség lehet a munkához. Plusz tudsz új lokális repókat indítani és helyi backupnak is megfelelnek a leklónozott repók.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Oké, ebben a konkrét esetben csak annyit, hogy ha egy új fejlesztéshez kell új repó, akkor _csinálsz_ akkor is, ha nem megy a távoli szerver. Aztán ha backup kell, max. felpusholod egy másik tárhelyre - ami akár egy másik fejlesztő gépe is lehet.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Besegítettem most egy munkába és a cégnél pár órára kiesett a repókat tároló szerver. A javítását összekötötték más karbantartással is, így kb. 4 órán át nem volt remote repó. A fejlesztőket megkérték, hogy ebben az időszakban ne pusholjanak, mert nincs hova, új repókat pedig nem kellett létrehozni. Szóval a munka ebben az időszakban is haladt rendben.

Ugyanígy saját tapasztalat, hogy a hazai mobilnetes és tömegközelekedéses viszonyok mellett végig lehet dolgozni több órás vonatutakat commitolással együtt, csak áram legyen. Aztán mikor célba érek, akkor megy a push a szerverre.

Kb. itt kezdődik, hogy milyen előnyt ad egy elosztott verziókezelő rendszer.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez mind szep es jo, de a kulonbseg az svn-hez kepest csak annyi hogy a 4 ora alatt nem egy commit lesz hanem tobb. Ez onmagaban eleg gyenge erv a git mellett...
(ezzel nem elvitatni akarom az elosztott VCS elonyeit, de szamomra a git hatalmas adminisztracio-igenyet a legkevesbe sem kompenzalja)

mercurialt esetleg hasznaltal mar, van vele tapasztalatod?

a tobb commit lenyegeben a verziokezeles.

Vagy ugy gondolod, hoygha nem lett volna internet, akkor most kiadjak a linux 4.0-at egy(!) kommitban egy CD-n?:)

tudod lehet ott branchet letrehozni, cherry-pick, git bisect megy minden szepen.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez mind szep es jo, de a kulonbseg az svn-hez kepest csak annyi hogy a 4 ora alatt nem egy commit lesz hanem tobb

Szép is lett volna, ha azért nem lehetett volna commitolni, mert nem érhető el a távoli repó. Vagy ha lett volna egy nagy commit, amibe minden ömlesztve kerül. És akkor ez még mindig csak a commit, a többi funkcióról nem is beszéve.
És ugye a 4 óra sem mindig csak ennyi, pl. amikor az ország két vége között 7-8 órát vonatozva végigdolgozom az utat.

Mercuriallal nem foglalkoztam, Git előtt a Bazaart használtam.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

igen, az svn-nek a commithoz kell a server, ez van :)
itt nyilvan kijon az elosztott VCS elonye

azert azt meg hadd jegyezzem meg, hogy mobilnetnel az svn teljesen jo, nagyon kicsi adatforgalmat csinal (felteve persze hogy nem modosultak nagy binaris file-ok), nem akarja gites modra az osszes branch teljes historyjat szinkronizalni

"azert azt meg hadd jegyezzem meg, hogy mobilnetnel az svn teljesen jo, nagyon kicsi adatforgalmat csinal"

Ebbe a "nagyon kicsi"-be a log, blame, diff és egyebek által generált forgalmat is beleszámoltad?
Plusz ugye az idő, amíg a bitek keresztül méltóztatnak kúszni az esetleg nem valami kapkodós mobilneten...

"nem akarja gites modra az osszes branch teljes historyjat szinkronizalni"

A git se akarja.

"Ebbe a "nagyon kicsi"-be a log, blame, diff és egyebek által generált forgalmat is beleszámoltad?"
igen, de mivel ezek jellemzoen eleg ritkan kellenek (legalabbis nem orankent, es nelkuluk is nyugodtan lehet fejleszteni), ez kb. nulla :)

""nem akarja gites modra az osszes branch teljes historyjat szinkronizalni"
A git se akarja."
nalam es az osszes kollegamnal igen.

"igen, de mivel ezek jellemzoen eleg ritkan kellenek"

Vagy inkább, SVN jól ismert korlátait figyelembe véve, mivel ezek jellemzően elég ritkán használhatóak... :)

A subversion-ös időkben én is ritkán használtam, és még ritkábban voltak a segítségemre, részben mert a history sok kívánnivalót hagyott maga után, másrészt hiányoznak az eszközök, amivel a history lényeges részét egyszerűen meg lehet találni. Ez alapjaiban változott azóta, hogy van olyan eszköz, amivel nemcsak egyszerűen lehet "szép" historyt csinálni, hanem abban bányászni is, mert pl. a 

log

parancsa tud a commit üzenetben és/vagy a patchben is grep-elni, sőt, csak egy adott függvényt érintő változtatásokat is meg tudja mutatni.

"nalam es az osszes kollegamnal igen."

Kevered a dolgokat: nem a git akarja, hanem ti.

teljesen masrol beszelsz...
nekem amugy nem volt gondom az svn-es loggal sem, bar teny hogy nem egy bisect, de attol meg mukodik (internetkapcsolat nelkul is :D)
ettol fuggetlenul ritkan van ra szukseg, az utobbi fel evben kb. egyszer hasznaltam git blame-et, szoval egy 1-2 oras utazas boven kibirhato nelkule

nem a git akarja, hanem ti
en nem akarom, megis csinalja...

http://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow…

Mondjuk én nagyon ritkán használom, mert ha valami repóra szükségem lesz, akkor azt letöltöm még a szűkös net-hozzáférés előtt.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

ahso...
szoval megoldhato ha eleve ugy klonozod
es gondolom ez attol meg az uj brancheket, es az azokban levo valtoztatasokat is lehuzza, ugye?

vegul is mind1, asztali gepen dolgozva nincs erre szuksegem, notebookon meg egyelore nem merult fel a kerdes (ott eddig csak svn-t hasznaltam, gond nelkul)

„megoldhato ha eleve ugy klonozod”

Igazából ez nem igaz. Leegyszerűsítve a "git clone" négy parancsot hajt végre egymás után:
- git init
- git remote add origin
- git fetch
- git merge
(igazából ez utóbbi kettő kiváltható a "git pull"-lal)

Ha megnézed, akkor a "git fetch" és a "git pull" is rendelkezik --depth paraméterrel.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Szerintem nem beszélek másról, csak arra is próbálok rávilágítani, hogy az eszköz képességei befolyásolják, hogy hogyan használják.
SVN log és blame képességei korlátozottak, ezért nehezen találtam meg, amit kerestem, ráadásul SVN history ritkán szép, ezért ha meg is találtam, sokszor akkor se segített vmi sokat, így ritkán használtam őket. Gitet sokkal egyszerűbb használni, a history is rendezettebb, ezért gyakrabban nézek utána dolgoknak.
Hogy mennyire "van rá szükség"... Én úgy találom, hogy jelentős mértékben segíti a kód megértését, ezzel könnyíti a munkámat, ezért nekem gyakran van rá szükségem.

Amúgy git blame-et én talán még annyit se használtam, mint te, amióta van line-level log (git log -L...), sokkal kényelmesebb és gyorsabb célt érni vele.

"en nem akarom, megis csinalja..."

És meg is mondtad neki, hogy nem akarod? Naugye :)

nekem az svn blame-mel pl. sosem volt bajom, egyszeruen ritkan jutott eszembe hogy tudni akarom ki irta az adott sort. Egyebkent pont ma volt egy ilyen, ugyhogy ma hasznaltam a git blame-et, egy par honapig valoszinuleg megint nem fogom :D

a git logja valoban jofajta, az amugy baromi idegesito gitk-ban is jol kezelheto, ez egyertelmuen a git mellett szol (mint sok mas feature, amit en is felsoroltam), de ez meg nem segit a problemakon amik engem zavarnak

És meg is mondtad neki, hogy nem akarod?
Ha kulon meg kell mondani hogy en NEM ugy akarom, akkor az azt jelenti hogy o eleve ugy akarja. Naugye :)

Hát igen...
Ha én is csak annyit akarnék megtudni, hogy az adott sort ki írta (pontosabban: ki módosította utoljára), akkor nekem se lenne bajom az svn blame-mel, vagy valszeg bármelyik másik blame-mel se. De ez ritkán (sose?) érdekel, az viszont elég gyakran, hogy miért módosította bárki is az adott sort, illetve hogy mely módosítások során alakult ki az adott sor mai formája. Akkor meg már mindegyik blame-mel felesleges köröket kell futni, csak némelyikkel kevesebbet, mint másokkal.

"Ha kulon meg kell mondani hogy en NEM ugy akarom, akkor az azt jelenti hogy o eleve ugy akarja. Naugye :)"

Az default fetch refspec a te ellenőrzésed alatt van, a fetch paraméterei, amik azt felülírják, még inkább. Innen nézve nekiállni azon problémázni, hogy jajj, mobilneten a git mi mindent "akar" letölteni, hát... mindegy is.

miért módosította bárki is az adott sort, illetve hogy mely módosítások során alakult ki az adott sor mai formája.
ez engem meg sosem erdekelt annyira hogy ezzel csesszem el az idot... ha valamiert megis ez lenne a perverziom, akkor sokkal egyszerubb es gyorsabb megkerdezni a fejlesztot hogy magyarazza el harom mondatban

Ilyenkor szokott orvul lecsapni az "írta" és az "utoljára módosította" közötti különbség.
Elég egy refaktorizálás miatti kódmozgatás vagy egy beljebb kezdés, és máris túl vagy az 5 másodpercen. Aztán ha ezekből több is van, ráadásul az idők során még egy-két változót is átneveztek, akkor egyből nyilvánvalóvá válnak bármelyik blame korlátai, még azé is, amelyik képes whilespace változásokat ignorálni vagy kódmozgást követni.

Hát ha már van, akkor igyekszek az előnyömre fordítani.
Szerintem ez nem időelcseszés és perverzió, hanem időmegtakarítás a verziókezelésben rejlő lehetőségek kihasználásával.
Nem mellesleg független attól, hogy az adott fejlesztő a) már rég elfelejtette, b) épp nem ér rá, mert megbeszélésen, szabadságon vagy betegállományban van, vagy sok időzónával arrébb éppen alszik, vagy c) már egyáltalán nem is dolgozik a cégnél.

De ha három mondatban el lehet magyarázni, akkor eleve nincs szükségem segítségre a megértéséhez.

( uid_4263 v | 2015. 05. 07., cs – 09:16 )

Ezért jó a git. Ha teszem azt a teljes github megpusztul, és sóval hintik a helyét, minden repository-hoz elég egyetlen valaki aki leklónozta, és megvan minden.

--
arch,debian,openelec,android

github egyben kezeli.
Belepsz a repodhoz es latod az issue-ket. A legtobb projekthez elegendo.

Szoval nem olyan kulon tortenet a verziokezelestol. Lehet kellene neki egy kulon branch az issue-knek es azt vagy clone-ozza az ember, vagy nem.
(nem branch, hanem lenne egy issue fogalom a git-ben)

A lenyeg, hogy ez most ilyen afterthought, az elejen a tervezesbol ez abszolut kimaradt.

A github jol megoldotta, egyebkent is rengeteg dolgot (pull request) jol prezentalja a felhasznalok ele, annyira, hogy valaki csak a webes feluletet hasznalja.
Igy az issue-khoz csak a webes felulet fel se tunik, hogy nem a repo resze.

Szerintem erre is gondolni kellett volna az legelejen... Csak ugy a bugokkal meg a security dolgokkal senki se szeret foglalkozni... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A Git egy verziókezelő rendszer forráskódok tárolására. Nem hibajegykezelő, nem Wiki-szoftver, még kenyeret sem szeletel. Vannak más szoftverek, amelyek ilyen adatok tárolására használják backendként, de eredendően nem arra van. Nem is kell, általában mindenkinek megvan a kedvenc hibajegy-kezelő és dokumentációs rendszere.
Érdekes, hogy máskor mindenre könnyen kiáltatok bloatware-t, de nem tűnik fel, hogy általatok áhított dolgokkal mennyire az lenne a rendszer.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…