[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi indirizzò:

> Vi consiglio di usare git --version > 1.5.1 e di leggere:
> - A tutorial introduction to git (for version 1.5.1 or newer)
>   http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Qualche altra cosa: perché GIT non segue il comportamento di 
CVS/SVN/quasi tutti ed è necessario fare "add" ad ogni "commit"?

Mi sembra una differenza gratuita. Per quanto mi concerne viola il 
principio di least-surprise.

Per evitare di fare commit di tutti i file è sufficiente elencare quell 
interessanti sulla riga di comando di "commit"...

«git-commit -a» dovrebbe essere il default, non il contrario.


> $ git diff --cached
> 
> (Without —cached, git-diff(1) will show you any changes that you've
> made but not yet added to the index.) You can also get a brief summary
> of the situation with git-status(1):

Ecco, vedi dove l'astrazione ha dei leak?
Cos'è l'index? (domanda retorica, ormai l'ho imparato)
Perché dovrei saperlo? git-diff non è certo plumbing.
"--cached"? Che cache? Non era l'index?
Per quanto mi riguarda sembra che ci siano due livelli di commit: quello 
nell'index e quello vero e proprio...


> Git tracks content not files
> 
> Many revision control systems provide an "add" command that tells the
> system to start tracking changes to a new file. Git's "add" command
> does something simpler and more powerful: git add is used both for
> new and newly modified files, and in both cases it takes a snapshot
> of the given files and stages that content in the index, ready for
> inclusion in the next commit.

Ok. Non vedo però il motivo di fare questo nel comando "add", il quale 
potrebbe essere una porcelain che chiama l'attuale "add". Chiamatelo 
"insert", "index-add", "index-insert", "frobnicate" ma non "add", uffa!

La mera esistenza di questo capitolo indica ce c'è qualcosa che non è 
chiaro. Come anche il caso precedente, d'altra parte.

Qui non sono gli utenti che non capiscono, è l'interfaccia che è 
progettata male.


> $ git log
> commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
> Author: Junio C Hamano <junkio a cox.net>
> Date:   Tue May 16 17:18:22 2006 -0700
> 
>     merge-base: Clarify the comments on post processing.
> 
> We can give this name to git show to see the details about this commit.
> 
> $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

Perché due comandi?
«git-show» non è altro che «git-log -1», no?
A me sembra più complicato ricordare due comandi piuttosto che una 
semplice opzione del primo. E avere due comandi vuol dire che mi leggo 
due pagine di manuale, che il completamento automatico cicla su di un 
elemento in più, che temo di trascurare sottili differenze, ecc...


> $ git reset --hard HEAD^ # reset your current branch and working
>                          # directory to its state at HEAD^
> 
> Be careful with that last command: in addition to losing any changes
> in the working directory, it will also remove all later commits from
> this branch. If this branch is the only branch containing those commits,
> they will be lost. Also, don't use "git reset" on a publicly-visible
> branch that other developers pull from, as it will force needless merges
> on other developers to clean up the history. If you need to undo changes
> that you have pushed, use git-revert(1) instead.

Perché "reset"?

Mi sembra che l'azione principale sia quella di cancellare dei cset.

"git-reset" lo vedrei meglio per una porcelain attorno "git-checkout 
-f". Anzi, per analogia a SVN lo chiamerei "git-revert".

In Mercurial l'analogo di git-revert è "hg backout" e "hg revert" fa 
quello che un utente SVN/Darcs/Bazaar si aspetterebbe.


> git-format-patch(1), git-am(1): These convert series of git commits
> into emailed patches, and vice versa, useful for projects such as the
> linux kernel which rely heavily on emailed patches.

Perché questa asimmetria? Uno esporta patch e l'altro le importa... :(


Spesso sono solo inezie, piccoli fastidi, ma si accumulano in fretta.

Dal punto di vista del design GIT è decisamente valido, ha solo alcuni 
tradeoff diversi da Mercurial, per cui non mi oppongo affatto al suo uso 
piuttosto che a CVS/SVN/BitKeeper/Perforce/Arch/Monotone.

Solo che, potendo scegliere, preferisco di gran lunga Mercurial.

Non è che qualcuno ha voglia di creare "ghit", clone dell'interfaccia di 
Mercurial ma che usa GIT?
O di provare a scrivere un backend GIT per Mercurial.
O di fare qualsiasi altra cosa che non mi faccia accorgere di usare GIT. ;)

-- 
Buongiorno.
Complimenti per l'ottima scelta.