[Linux-Biella] Differenze cvs e svn

[Paolo Ciarrocchi]

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

E questo lo si puo' fare anche con git.

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

Tutto e' sempre una questione di punti di vista :-)

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

Stai un po' estremizzando in commento di Linus, credo che non sia un
problema perdere la modifica alla versione del Makefile per lui :-)

In generale, trovo comodo fare delle modifiche, aggiungerle/toglierle
all'index e fare:
$ git diff --index
per vedere quello che verra' incluso nel prossimo commit.

Ma come ho detto in precedenza, se non ti piace ti crei un alias a
commit -a e ti dimentichi della staging area.

[...]
> >     * This allows excellent merge conflicts management: git diff
> > --base, git diff --ours, git diff --theirs.
>
> Cosa fanno? "man git-diff" non ne parla.

Non ne ho la minima idea :-)

Ma Linus credo si trovi a gestire i "merge" piu' complessi in
assoluto, io invece non ho mai problemi :-)

> 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! :)

Yeppa.

[...]

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

...e veloci...Cof cof...
http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html

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

Ama "stressare" il fatto che git fa il tracking dei contenuti e non
dei file (nomi di)

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/