Linux Journal racconta la storia di Git

Conoscete tutti la storia di Git? È presumibile che tutti sappiano come l’autore del più popolare software di versioning sia Linus Torvalds, certo, ma i dettagli della sua genesi?

Questo lungo articolo di Zack Brown per Linux Journal, racconta moltissimi succosi dettagli in merito a come Git è nato e cosa ha portato Torvalds a compiere determinate scelte.

Ad esempio, sapevate che inizialmente non esisteva nessun sistema di versioning per gestire le patch? I contributori dovevano inviare messaggi al gruppo Usenet del Kernel e lo stesso Torvalds, a mano, gestiva i merge. Questo significava che l’unica via per risalire ad una determinata modifica era di effettuare un comando diff su due intere versioni, con chiaramente tutti i disagi che questo comportava.

Sapevate poi che, non sopportando CVS e subversion (i software di versioning disponibili negli anni 2000), Torvalds optò per una soluzione commerciale, closed-source, chiamata BitKeeper? Pensate un po’, il software open per antonomasia, il più importante di tutti, colui che ha determinato l’inizio dell’era Linux, è stato gestito da un software chiuso. Incredibile, vero? A tutte le (comprensibili) critiche mosse nei suoi confronti l’affezionato dittatore benevolo rispondeva semplicemente…

Non sono un fanatico del software libero

Inevitabilmente i nodi per BitKeeper vennero al pettine quando Andrew Triggel (creatore di Samba e co-creatore di rsync) tentò di fare il reverse engineering del prodotto usato da Torvalds, Larry McVoy (proprietario della società BitMover distributrice di Bitkeeper) decise di impedirne il suo utilizzo da parte degli sviluppatori del Kernel, bloccandone di fatto gli sviluppi (da notare come la licenza di utilizzo di Bitkeeper per il progetto Kernel non prevedesse il pagamento di denaro).

A questo punto accadde qualcosa mai successo dal 1991: Torvalds smise completamente di sviluppare il Kernel e creò Git.

Il resto, come si dice, è storia.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

9 risposte a “Linux Journal racconta la storia di Git”

  1. Avatar Kim ALLAMANDOLA

    Personalmente NON gradisco git, ha di fatto oscurato vari dCVS precedenti, ognuno con le sue peculiarità (mercurial, fossil, bazaar ecc) che osservandosi l’un l’altro evolvevano bene, presenta una complessità MOLTO maggiore, inutile nella stragrande maggioranza dei casi, per non dire dannosa (disastri sulla history del repo) ma capisco che a Linus Torvalds o comunque per lo sviluppo del kernel servisse. Il punto è perché c’è stato tutto questo effetto pecora al di fuori del kernel.

    Questo non mi spiego se non col tipico fanatismo ignorante che molti nella community GNU/Linux han mostrato di possedere e che anziché aiutare lo sviluppo rovina. Mi domando in particolare perché tanti han lasciato svn per git quando per un decennio almeno han avuto alternative a git altrettanto efficienti e pure più comode, ad esempio. Mi domando perché tanti sono ancora legati a cvs…

    ‘Somma interessante l’analisi storica e ringrazio per la segnalazione, ma un po’ di critica mi sarebbe piaciuto trovarla 🙂

  2. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Oscurare altri software penso sia stato l’ultimo degli obiettivi di Git. Semplicemente Torvalds voleva creare qualcosa adatto alle proprie esigenze, che poi questo abbia portato alla quasi estinzione dei “concorrenti” penso sia una conseguenza dettata dalla qualità del software.
    Ma in ogni caso, in merito alle critiche che chiedi: l’articolo originale è un resoconto storico, senza giudizi tecnici, perché cercare la polemica sempre e ad ogni costo?

  3. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Beh ma poi la scelta è di ognuno no? La musica che esce dai reality domina le classifiche, ma poi cosa finisce nel tuo lettore musicale dipende da te…

  4. Avatar Kim ALLAMANDOLA

    Certo che si, ma un conto è l’ascoltatore occasionale che prende la musica del reality di turno perché quello conosce, gli interessa solo “della musica”, non ha voglia di approfondire, è diciamo un mero consumatore che se ha il prodotto da consumare bene se non lo ha pazienza; ben altro conto è il professionista. Lui DEVE conoscere non solo ciò che usa ma ciò che c’è sulla piazza per fare il suo mestiere in n modi e declinazioni diverse.

    Che l’utente enterprise non approfondisca mi stà bene, il suo compito è fare una cosa ed una soltanto non troppo diversamente dalla vecchia catena di montaggio, ma che lo STUDENTE, ovvero qualcuno che è li per imparare, che dovrebbe avere una gran sete di conoscenza, o il tecnico che dovrebbe conoscere, vivere e dominare la tecnica del suo settore non vadano oltre “la corrente di turno”, spesso proprio senza conoscere NULLA al di fuori di essa questo francamente è assurdo. Già mi incavolo io quando qualcuno mi contesta che sul CV metto “admin GNU/Linux, {Free,Open}BSD, Solaris” dicendo “devi scrivere Linux/Unix così tutti capiscono” e poi magari dover dire “no, guardi, HP_UX l’ho visto un paio di volte anni fa ai tempi dell’uni, AiX non l’ho praticamente mai usato, True64 so a malapena che esista, NetBSD e DragonFly a parte qualche esperimento personale anni fa non l’ho mai usate, …”. Questo per me NON va bene. Non funziona ed è dannoso per tutti.

    Non possiamo dire all’americana: siccome fare un tecnico è difficile facciamo in modo di non aver bisogno di tecnici, siccome il progresso non si parametra in un CDA facciamo gestire la ricerca ad un manager con metodi rigorosi, digeriamo l’ITIL con la sua massa di banalità (e volumi costosi, non parliamo di corsi e certificazioni). Non funziona. Può SEMBRARE che vada nel breve, anche bene, poi crolla. Oggi questo stà accadendo alla community FOSS: siamo migliorati dal tempo in cui ricompilavamo il kernel ogni mese e scaricavamo patch oscure per far andare un pezzo di hw del nostro desktop, oggi il kernel non lo guardiamo manco più lato server… Però stiamo perdendo pezzi a manetta, abbiamo soluzioni che non conosciamo in produzione, abbiamo sistemi talmente complessi che non riusciamo a comprenderli, troppo spesso andiamo a tentoni (e Google e Stack*) per cercare di mettere l’ennesima pezza di scotch all’ennesimo problema che non comprendiamo.

    Git è un esempio ma il mare è fatto di gocce. Non ce l’ho certo con Torvalds, dico che git non mi piace perché oscenamente complesso quando nel 99% dei casi l’uso di un SCM è semplicemente co, commit, push/pull, commit e al massimo qualche branch privato. A lui serviva così, l’ha positivamente condiviso, altri l’han trovato utile. Ottimo. Ma sono abbastanza certo che l’80% se non il 90% dei suoi utenti l’ha preso, magari vendo da svn (a sua volta scelto perché “un moderno cvs”), solo perché l’ha fatto Linus Torvalds. Senza sapere che esistono tante altre alternative da ben prima di git che non ha mai cercato semplicemente perché nessuno gliele ha messe sotto il naso. Voglio dire se sviluppi ti preoccuperai di farlo con gli strumenti adatti no? Avrai letto the mythical man month, in particolare il capitolo sugli “sharp tools”… Sennò che sviluppatore sei, quello che ha letto “programming in 24h” e s’è buttato nella lotteria del momento?

    Se tutti taciamo chi viene dopo dovrà prendersi facciate su facciate prima di realizzare quel che già sappiamo, se lo spieghiamo risparmiamo a chi viene dopo di fare gli stessi errori ogni volta senza quindi avanzare di un millimetro. Dovrebbe farlo la scuola, certo, ma come dire, non si finisce mai di imparare e ripetere giova…

  5. Avatar Kim ALLAMANDOLA

    Non per cercare la polemica (in effetti è un po’ un mio difetto insieme alla logorroicità) ma per generare una critica costruttiva: mercurial e pure bazaar quanto a qualità non avevano nulla di inferiore a git, anzi erano assai più semplici e lineari, fossil e monotone pur con le loro peculiarità che possono piacere o meno non hanno nulla da invidiare a git…

    Quel che mi piacerebbe venisse fatto notare è come la community GNU/Linux vada dietro al personaggio (giustamente) famoso un po’ come gli aristotelici andavano dietro al loro maestro anziché fermarsi a riflettere ed estendere le proprie conoscenze come insegna il metodo scientifico, galileiano. Oggi va di moda git e sono ben sicuro che se domani Linus Torvalds lo considera deprecato e passa ad altro così farà la gran parte della community GNU/Linux, non legata al kernel o ai suoi sviluppatori. Idem vale per il fanatismo che c’è per Docker/lxc/d e l’ignoranza sostanziale che c’è delle jails (FreeBSD) o delle zones (OpenSolaris/IllumOS) o dei commenti di Andrew Morton al tempo su zfs. Se questa massa di persone si guardasse intorno scoprirebbe un mondo interessante, con cose positive e negative e potrebbe di conseguenza prendere il buono, evolverlo, e scartare il cattivo. La vecchia massima “la guerra è la lezione della storia che i popoli non imparano mai abbastanza”. Questo non è mai stato un problema sino ad un po’ di anni fa, c’era varietà, competizione e collaborazione, oggi lo è diventato e si polarizza sempre di più.

    Per continuare con l’esempio: quanti sono corsi su GitHub abbandonando i vari SF, BerliOS, Savannah, … e adesso per un cambio di proprietà sono corsi in massa su GitLab? Riesci a trovare una differenza tecnica, sostanziale, materiale, razionale per spiegarlo se non come il fanatismo e l’effetto pecora? Dopotutto GitHub e GitLab sono due piattaforme proprietarie, semi-aperte, gestite da una singola azienda. Sono essenzialmente UGUALI. Possibile che ci si debba tutti concentrare o seguire il leader di turno? Poi qualcuno da a me dell’estremista quando dico che stiamo andando male, che il FOSS stà diventando lavoro gratis per 4 gatti che lo integrano in prodotti proprietari ecc.

    Non so se sia per frustrazione o gusto polemico, ma sono sinceramente convinto che un po’ di sana, pungente, fastidiosa, caparbia, donchisciottesca critica sia non solo opportuna ma necessaria. Se non ci confrontiamo, se non ci facciamo le pulci non andiamo lontano. Conoscere la storia è necessario, ma non sufficiente, bisogna analizzarla e comprenderla per imparare da quel che è stato e migliorarlo nel futuro.

  6. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Io credo che la maggior comodità di GIT sia dovuto al fatto che crea copie locali del repository su cui poter lavorare, quindi sempre disponibili anche senza una connesione, al contrario di SVN che è un repository centrale, la cosa può funzionare in ambito enterprise dove non si hanno problemi, ma per uno sviluppatore indipendente (che magari lavora a casa o in ufficio poi si deve spostare in treno per arrivare da un cliente) potrebbe non essere così comodo, e ormai per GIT esistono tantissimi strumenti per editor, IDE, GUI che per molti sono indispensabili. Bazaar è fatto molto bene ed è molto più semplice non incasinarsi come su GIT e con GNU Savannah fanno una bella accoppiata, spero che non sia abbandonato come progetto

  7. Avatar Kim ALLAMANDOLA

    Hem, questo lo fanno da ANNI tutti gli altri dCVS, nati ben prima di git, da bazaar a mercurial passando per fossil, monotone e un mucchio di altri meno noti… Questo non è una caratteristica di git o che git ha inventato. Quel che git ha inventato è la “storia editabile” che probabilmente sarà stata assai utile a Linus Torvalds e altri ma in generale è fonte di disastri niente male, è troppo facile incasinare un repo se ci si sbaglia…

    Sull’integrazione e le GUI idem git non è né il primo ne il solo: SUN includeva mercurial in Netbeans e SUNStudio anni prima che git nascesse, GUI per mercurial e bazaar ci sono da un mucchio di tempo, pure per svn…

    Su bazaar in ultimo: è stato abbandonato anni fa. Semplicemente gli sviluppatori han detto: “visto che oramai praticamente tutti usano git e essenzialmente git, noi, hg, fossil, … hanno una sintassi, un uso, sostanzialmente intercambiabile rinunciamo a sviluppare, sarebbe una perdita di tempo”.

  8. Avatar Ivan Guerreschi
    Ivan Guerreschi

    Grazie mille per le precisazioni, mi dispiace per bazaar, per quel poco che l’ho usato mi pareva ottimo rispetto a git, che mi hanno fatto conoscere e forse per moda ha influenzato anche piccoli lavori che avrei potuto gestire con altre soluzioni più semplici

  9. Avatar Kim ALLAMANDOLA

    È proprio il mio punto: l’uso “base”, che è quello della stragrande maggioranza degli utenti, e un sottoinsieme dell’uso di TUTTI gli utenti, è praticamente uguale, come del resto le loro caratteristiche per ogni dCVS, git compreso, da anni prima che git nascesse, banalmente
    git clone $url
    hg clone $url

    bzr branch $url
    fossil clone $url

    lo stesso vale per commit, push/pull ecc, git essenzialmente ha solo (molte) cose in più che lo rendono certamente più utile al suo creatore ma solo più complesso (e pesante come install) rispetto agli altri. Anche (quasi) tutti gli altri han avuto GUI e WebUI proprie o di terze parti, fossil per esempio include addirittura un mini-webserver e si fa proxare al volo dai soliti Apache, NGINX ecc… Ora mercurial (molto amato in ambito SUN) è del 2005, come bazaar, darcs (da sempre non molto usato) è del 2003 come monotone, fossil è giovane, nato nel 2006. Possibile che non l’utente “casuale” ma lo sviluppatore di un progetto magari molto rilevante nella community, che sviluppa magari da un ventennio, non se ne sia accorto sino a quando Linus Torvalds ha annunciato git?

    Capisco l’inerzia: sei con svn o cvs da una vita, funziona bene per te, ha funzionato bene per anni e non ti interessa cambiare anche se riconosci un possibile miglioramento. Ma com’è che cambi idea proprio quando Torvalds fa un articolo su git? Non c’è nulla di male capiamoci, solo è un sintomo di una community che non si guarda intorno e anziché scegliere di evolvere per desiderio e bisogno lo fa seguendo in modalità pecora il leader carismatico di turno. Ecco, questo è “male”, nella storia sappiamo che sistemi in cui tutto ruotava intorno ad un leader tanto bene non finivano, anche ad avere il miglior dittatore buono a vita (Python, (ex)BDFL, alias G. Van Rossum) questo è comunque una persona i cui interessi e la cui vita materiale sono spesso inferiori alla vita utile/potenziale di un progetto. Questo non mi piace, non mi fa sentire sicuro. Ai tempi d’oro della community c’erano sempre soggetti carismatici, come è normale che sia, la loro (dotta) opinione era sempre ascoltata, ma ognuno comunque faceva i propri conti e le proprie scelte, non c’era il gregge che c’è oggi e non c’era manco la percezione di gregge dove ognuno si sente “piccolo piccolo” e “lontano” dall’inarrivabile leader di turno. Ai tempi nei ng era normale chiacchierare con Stallman, Torvalds, Pike, Wall, … prima di rispondergli magari si rileggeva con più attenzione rispetto ad altri post ma tutto finiva li. Adesso se dici che una trovata di uno di questi non ti piace c’è il coro di dissenso che ricorda i comizi del fascio.

    Vabbé mi scuso per il lungo rant… Spero serva a qualcuno come invito a guardarsi intorno in autonomia 🙂

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *