Perché i DVCS sembrano avere tutti una fobia irrazionale di cambiamenti non impegnati?

Proveniente da un background SVN, una delle cose più difficili a cui abituarsi quando si lavora con i sistemi DVCS è il modo in cui tutti sembrano considerare qualsiasi cambiamento non confermato come una bomba a orologeria.

In Mercurial, se provi a recuperare le modifiche e hai delle modifiche non confermate nella tua copia di lavoro, devi saltare attraverso i cerchi per farlo unire le modifiche in arrivo. Prova a cambiare ramo? Ti costringerà a scartare tutto e poi dovrai immediatamente scartare tutto dall'altra parte. (SVN non ha problemi con nessuno di questi scenari.)

Git è più o meno allo stesso modo. Sto lavorando fianco a fianco con un altro sviluppatore su un progetto e ho appena provato a scegliere uno dei suoi impegni nel mio fork. Si è rifiutato di consentirmi perché ho apportato modifiche non impegnate nella mia copia di lavoro, su file completamente diversi da quelli modificati nel suo commit. Non c'è nemmeno un'opzione di unione; a quanto pare devo prima nascondere le mie modifiche!

Se una persona dovesse trattare qualcosa di completamente innocuo con tale estrema cautela, la definirei una "fobia", una paura irrazionale che dovrebbe essere considerata come un disturbo mentale. Ma Git e Mercurial sono stati progettati da due diversi team di sviluppatori intelligenti e razionali, quindi devo chiedermi se sanno qualcosa di cui non sono a conoscenza.

C'è una ragione tecnica che giustifica questo atteggiamento nei confronti di cambiamenti non impegnati? E se è così, perché il problema in questione sembra esistere solo sui DVCS?

1. Nel mondo DVCS gli commit sono economici e la storia è mutevole. WIP può essere "sporco", come vuoi: e non riesco a vedere alcun motivo per "eliminare il mio stato corrente nel changeset per la memorizzazione"
2. La cronologia SVN è lineare, quindi - è necessario unire le bozze alle modifiche delle nuove revisioni. DVCS usa (nativamente) DAG, e la testa aggiuntiva (commit + pull + up) per la storia divergente è più sicura, che fondere al volo le directory di lavoro modificate con le modifiche esterne recuperate
3. Quando si cambia (in qualche nodo ) il WC modificato in Subversion, si elimina una potenziale unione aggiuntiva (contrariamente a "commit in old" - "switch" - "merge 1 rev. Range") ... e sappiamo: si fonde in SVN non sono il lato perfetto dello strumento, mentre non è affatto un problema per i DVCS

Curriculum vitae

Non è una fobia, è (a volte dura) l' applicazione di buone maniere "commettere spesso" (gli utenti SVN a volte hanno paura di questo stile)

E, infine, hg qnew|qpop|qpushè un piccolo prezzo equo per la pulizia e l'ordine

Quando si unisce o si seleziona la ciliegia git, si crea immediatamente un commit. L'operazione non è completa fino a quando il commit non è terminato e parte della cronologia.

Ora, cosa accadrebbe se gitti permettessi di sorvolare le tue modifiche non confermate nella tua directory di lavoro? Avresti difficoltà (più o meno) a distinguere tra i cambiamenti / i conflitti di cui devi occuparti per l'unione / selezione delle ciliegie e i cambiamenti che ti sei presentato. Inoltre, sarebbe quasi impossibile per te testare ciò che stai effettivamente commettendo.

Pertanto, forzare una directory di lavoro pulita per le situazioni di unione aiuta a mantenere le cose semplici e gestibili. Dopotutto, tutto quello che devi fare è riporre le modifiche senza impegno prima dell'unione e successivamente cancellarle. Si noti che nel flusso di lavoro

git stash
git pull
git stash pop

hai due (!) operazioni di unione. Uno che unisce il tuo ultimo commit con le modifiche in entrata e uno che unisce le tue modifiche non confermate al commit di unione risultante. In questo modo, hai sempre e solo bisogno di unire due cose in una, evitando la confusione che potrebbe derivare dal tentativo di unire tre cose in una in un'unica operazione mentre provi a ignorare queste tre cose. Il git stash/ git stash poprende semplice ed esplicito che si stanno ignorando le modifiche senza commit per l'unione.