Liverpool” post=86876
Sì, certo, ogni commit in git scatta una fotografia dell’intero repository, se tu gli dici di tornare al commit 5 con il primo comando che ti ho detto lui ripristina tutti i file presenti all’epoca, il file di classe apparirà come era stato modificato nel commit 4 e l’immagine1 nella commit 3.
Allora mi sorge un dubbio: perché dobbiamo aggiungere i file nella staging area prima del [tt]commit[/tt] se comunque Git “scatta una fotografia dell’intero repository”?
Perché forse mi sono espresso male: il commit scatta una fotografia della staging area, e non qualsiasi file presente nella cartella di lavoro compresi quelli non aggiunti nella staging area. Tutti i file
mai entrati nella staging area, come i file ignorati, non sono mai ricordati, se torni indietro nella cronologia, cambi ramo e operazioni simili, questi file ignorati rimangono sempre tali e quali. EDIT in realtà l’espressione “il commit scatta una fotografia della staging area” può essere ancora ambigua perché potrebbe far pensare che la fotografia contiene solo i file modificati: no, contiene tutti i file che fino a quel momento sono stati aggiunti al progetto con un [tt]git add[/tt] e poi non sono stati successivamente rimossi.
Riferendomi a “intero repository” intendevo dire che un commit memorizza lo stato di tutti i file in blocco, in contrapposizione al funzionamento di CVS che ha una cronologia separata per ogni file. Vedi la prima critica qui: http://en.wikipedia.org/wiki/Concurrent_Versions_System#Criticism
Esempio di Git: https://github.com/giordano/guidagit/commits/master per ogni commit puoi visitare tutti i file presenti all’epoca (pulsante “browse code”)
Esempio di CVS: http://cvs.savannah.gnu.org/viewvc/auctex/auctex/ ogni file ha la sua revisione. Non so se sia possibile dire “fammi vedere tutti i file all’1 gennaio 2013”, a parte usando i tag (ma non è che uno può creare un tag per ogni commit…) (P.S. fortunatamente da qualche mese anche AUCTeX si è convertito a git).
Il funzionamento dei vari VCS moderni è molto simile, così come comune è l’interfaccia utente: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_commands per ogni operazione, i nomi dei comandi scelti dai vari software sono al più due o tre. Quello che cambia sono le opzioni particolari utilizzate da ciascun comando, da questo punto di vista qualcuno dice che git ne ha troppe 😀 Comunque è impossibile negare che git sia il DVCS che ha avuto maggior successo (considerando i tre grandi git, mercurial, bazaar), qui per esempio c’è una statistica basata su tutti i progetti registrati su Ohloh (oltre mezzo milione): https://www.ohloh.net/repositories/compare Qui un’altra statistica basata sui pacchetti presenti in Debian (quasi 14 mila): http://upsilon.cc/~zack/stuff/vcs-usage/ oltre il 60% dei pacchetti sono mantenuti usando git, invece mercurial e bazaar raccolgono le briciole.
In generale, i DVCS sono tremendamente utili, ti permettono di lavorare con maggiore libertà perché hai sempre la consapevolezza di poter tornare indietro a uno stato precedente e ti permettono addirittura lavorare contemporaneamente su due binari paralleli, tracciando tutti i cambiamenti compiuti. Dubito che sistemi di backup siano utili da questo punto di vista (per lo sviluppo collaborativo sono del tutto inutili). Sono fermamente convinto che anche gli utenti di *TeX, siano essi autori di documenti (soprattutto quelli più grossi e importanti) o sviluppatori di classi e pacchetti, possano trarre grande vantaggio dall’uso dei DVCS.
Liverpool” post=86876Forse il [tt]commit[/tt] aggiunge fisicamente una copia dei file aggiunti e un semplice riferimento per gli altri presenti nel repository basandosi non su ciò che c’è nella working directory, ma su ciò che è scritto nel suo database?
Con “gli altri presenti nel repository” intendi i file mai entrati nella staging area? In questo caso ti ho risposto sopra.
Liverpool” post=86876Grazie. Ho visto che hai aggiunto l’elenco dei comandi alla fine.
Grazie a te per l’idea, è davvero utile. Non c’avevo mai pensato, ma effettivamente mi è capitato più di una volta di ritornare a leggermi mezza guida per trovare un comando che sapevo essere presente, il riassuntino di tre pagine è molto comodo per questo!