[Linux-Biella] Differenze cvs e svn

[Paolo Ciarrocchi]

On 10/3/07, Emanuele Aina <em a nerd.ocracy.org> wrote:
> 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.

What?
Non e' necessario fare git add dopo ogni commit.
Basta usare git commit -a

a|--all

    Tell the command to automatically stage files that have been
modified and deleted, but new files you have not told git about are
not affected.


> 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.

vedi sopra.

> > $ 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...

Sto riportando il tuo dubbio sulla ml di git.

> > 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.

Non ti seguo.
Usa git commit -a e dimenticati di git add, se preferisci.

> 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?

Non mi sembra, rileggiti le man pages dei due comandi.

> 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.

hg revert sposta l'HEAD o fa il revert di un commit? (quindi nei log
vedo prima il commit, poi il suo revert)

> > 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... :(

Tu preferiresti avere un unico comando, con opzioni per esportare/importare?

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

Ciao e grazie.

-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com