[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi riportò:

> Git does it differently. By default, git commits the content of the
> index, and only this. 

Sì, ma secondo me questo è un dettaglio implementativo.

> git commit -a gives roughly the equivalent of
> what other systems do. Indeed, there are many concrete reasons why
> git's way to manage the index is good (and leads to unique features of
> git):
> 
>     * You can do selected files commit with a fine granularity,
> telling git what you want to do little by little (git add file to add
> the full content of the file to the index, git add -i or git-gui to
> add the content hunk-by-hunk, or even use the hunk splitting feature
> of git add -i).

Questo lo si puo fare in altri modi senza index:
* elencando i file al momento del commit
* usando darcs/hg record e selezionando interattivamente file e hunk

>     * This selected files commit can help you to keep an uncommited
> modification in your tree for a reasonably long time. For example, you
> can increment the version number in the Makefile some time before a
> release, and use this as a reminder.

Ok, questo con gli altri non si può fare, ma non mi sembra che il gioco 
valga la candela.

Usare cambiamenti non committati credo sia un pessimo modo di segnarsi 
le cose da fare...

Oltretutto credo un VCS dovrebbe evitare di invogliare l'esistenza di 
cambiamenti che rimangono non committati per lungo tempo, in quanto sono 
quelli che vengono persi in caso di rottura del disco, «rm -Rf /», eccetera!

>     * You can perform several small steps for one commit, checking
> what you did with git diff, and validating each small step with git
> add or git add -u. Typically, you can apply a broken patch, updating
> the index, with git apply --index, and then fix the patch. git diff
> --cached will show you your fixes, while git diff HEAD will show you
> the combined diff.

"darcs amend" serve alla stessa cosa ma è molto più semplice e non 
introduce concetti nuovi.

Applichi una patch malfunzionante, commit, correggi, fai il diff delle 
tue modifiche e poi fai amend.

Per le modifiche cumulative semplicemente nomini esplicitamente il 
commit precedente alla patch.

Con Mercurial la punta è "-1" e il suo genitore sarà "-2", quindi "hg 
diff -r -2".

>     * This allows excellent merge conflicts management: git diff
> --base, git diff --ours, git diff --theirs.

Cosa fanno? "man git-diff" non ne parla.

Comunque a occhio credo che non sia necessario un index esplicito, la 
stessa cosa con gli altri sistemi viene fatta indicando esplicitamente i 
changeset.

Basterebbe segnare durante un merge gli id dei changeset in qualche file 
nella directory .hg (ad esempio .hg/ours, .hg/theirs, .hg/base) e 
aggiungere i relativi parametri a "hg diff".

>     * This allows git commit --amend to amend only the log message if
> the index hasn't been modified in the meantime.

Oh, allora ce l'ha anche GIT! :)

Supponendo di avere "git-amend" invece di "git-commit --amend" si 
potrebbe aggiungere un parametro "--edit-only" o "--ignore-tree" che 
ignora i cambiamenti al working tree.

Oppure fare "git-checkout -f" e poi "git-commit --amend".

Oppure avere una estensione "shelve" come quella di Bazaar che consente 
di mettere temporaneamente da parte i cambiamenti e fare

git-shelve # lascia il wt pulito
git-commit --amend # modifica solo il messaggio di commit
git-unshelve

Una estensione del genere è stata proposta anche sulla ml di Mercurial, 
spero venga integrata presto perché è molto utile anche per altri scopi.

> So, while using git commit -a is perfectly fine with the simple cycle
> "edit/review/commit", making it the default would make other workflow
> less natural.

Boh, le alternative mi sembrano tutte più semplici e con una curva di 
apprendimento più dolce, seguendo il principio di rendere semplici le 
cose semplici e fattibili le cose complicate.

GIT rende uguali le cose semplici e complicate, ma non sono sicuro sia 
una cosa buona. :)

> Indeed, the real reason according to Linus is more philosophical: git
> is a content tracker, and a file name has no meaning unless associated
> to its content. Therefore, the only sane behavior for git add filename
> is to add the content of the file as well as its name to the index.

Ok, ma io non uso un VCS per motivi filosofici, come non uso il software 
libero per motivi filosofici.

Per di più detto da un pragmatico come Linus lo interpreto solo come una 
battuta. ;)

-- 
Buongiorno.
Complimenti per l'ottima scelta.