[Linux-Biella] Differenze cvs e svn

[Emanuele Aina]

Paolo Ciarrocchi precisò:

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

Ho capito, perà secondo me dovrebbe il default.
Sono pigro, ricordarmi di mettere parametri al comando di commit è molto 
sbattimento.

> Sto riportando il tuo dubbio sulla ml di git.

Grazie.
Giusto per dimostrare che le critiche possono essere e magari portare a 
miglioramenti per tutti.

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

Un capitolo che spiega il modello interno di GIT giusto per spiegare 
come funziona un comando ovvio come "add" mi dà l'idea che ci sia 
qualcosa di sbagliato.

> Usa git commit -a e dimenticati di git add, se preferisci.

Ma devo ricordarmi di "-a". Con gli altri VCS non devo ricordarmi di 
nulla, invece.

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

Oops.
"git-show" è generico e può mostrare anche cose che non sono i messaggi 
di log.

Quindi "git-show" è plumbing, "git-log" è porcelain.

Aggiungerò "git-show" alla ignore-list dei comandi git...

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

"hg/darcs/bzr/svn revert" non agiscono sulla storia, ma solo sulla 
working directory.

Sono l'analogo di "git-checkout -f", annullano i cambiamenti non committati.

Invece "hg backout" fa il revert di un commit, quindi nel log vedi prima 
il commit e 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?

No, due separati vanno benissimo.

git-import-patch
git-export-patch

O qualcosa di simile.

-- 
Buongiorno.
Complimenti per l'ottima scelta.