On 03/23/2012 04:18 PM, Marco Amadori wrote: > Il 23 marzo 2012 14:46, Stefano Cavallari <spiky.kiwi@xxxxxxxxx> ha scritto: > > Ti ringrazio per l'analisi che hai effettuato, per piacere della > discussione commenterò alcune key features che elenchi, premettendo > che sembra esserci una differenza filosofica profonda tra l'approccio > allo sviluppo che uso io e il tuo, senza per questo dire che il mio è > migliore. > >> In git ci sono comandi che cambiano la history. Anche in hg, ma sono >> disabilitati per default. Mi sembra una scelta migliore, la history va >> cambiata solo in caso di effettiva necessità, si possono creare problemi >> noiosi ad altri committers. > > Questo è vero ma non devi limitarmi, dammi potere, sono maggiorenne e > sò quando usarlo. Non lo mettevo assolutamente in discussione; ma il default conta molto nel far capire cosa è assolutamente normale e cosa va fatto con un po' di cautela e non è immediatissimo. Il disabilitarlo di default è un modo, un altro è dargli posizioni diverse nella documentazione e visibilità; su questo si può discutere. Vedo che versioni recenti di git mostrano solo comandi semplici nel --help; peccato che nell'help dei comandi stessi poi non ci sia la stessa scelta, almeno nel separarli. > > Io riscrivo la storia spesso, per esempio per fornire le mie patch in > testa tramite rebase (feature non dagli inizi presente in hg) e per > riorganizzare i commit dopo fasi di sviluppo molto caotiche. Anche io. Ma prova a far fare un rebase con conflitti ad un novizio, secondo me si incasina e finisce che perde tutto o committa grafi impensabili. > > E dopo la sessione di editing fuoriosa con commits parziali, > riorganizzarsi l'history inmaniera più logica per sé e gli altri. > > Fondamentale nel mio workflow. > >> Poi non mi piace che sia "normale" ignorare file sotto controllo di >> revisione. > > Questo non mi è chiaro, le cose che metti in .gitignore puoi comunque > tracciarle. > MMh non ho capito, espandi con un workflow tipico. >> Inoltre i file da committare vanno aggiunti esplicitamente, preferisco >> il comportamento di default di hg di committare tutto se non >> diversamente indicato. Spesso uso hg record per selezionare cosa >> committare, ma a livello di chunk non a livello di file. La granularità >> a livello di file di git add, e più in genere la gestione manuale della >> gestione dell'index le trovo assolutamente inutili. > > Questo lo pensavo anch'io all'inizio, ora invece apprezzo e uso > tantissimo l'index e i tool per gestirlo. Anche qua, fammi un esempio :) > > Il risultato è che i miei commit e la mia history sono infinitamente > più puliti, condizione necessaria per scoprire regression e per > interagire con altri sviluppatori. Pienamente d'accordo che cambiare la history locale è molto utile, infatti uso molto rebase e mq. >> Su hg c'è "hg serve" crea un semplice webserver out of the box da cui si >> può pullare e navigare nella history e nei tree. È veramente utile >> quando in una lan si scambiano commit senza avere un server >> centralizzato, ma anche per navigare in locale il repository. In git non >> c'è niente di altrettanto veloce e pulito (e non ditemi di usare github >> e simili, non è una soluzione). > > Immagino che tu possa avere ragione, per gli usi occasionali git > format-patch o la mia installazione di gitolite coprono le mie > esigenze alla perfezione, ma anche un link simbolico su /var/www non è > la fine del mondo. BRRR :) > Diciamo che per ora non me l'hai venduto, ma tengo le porte aperte ;-) > Anche di qua non si chiudono mai :)