Perché i DVC sembrano avere tutti una fobia irrazionale di modifiche non vincolanti?

Question

Perché i DVC sembrano avere tutti una fobia irrazionale di modifiche non vincolanti?

#1 da (4 voti)
#2 da (1 voti)

10

Venendo da uno sfondo SVN, una delle cose più difficili da abituare quando si lavora con i sistemi DVCS è il modo in cui tutti sembrano considerare qualsiasi cambiamento non impegnativo come una bomba ad orologeria.

In Mercurial, se provi a recuperare le modifiche e hai qualche modifica non vincolante nella tua copia di lavoro, devi passare da un anello all'altro per fare in modo che unisca le modifiche in entrata. Prova a cambiare rami? Ti costringerà a mettere da parte tutto e poi dovrai immediatamente annullare tutto dall'altra parte. (SVN non ha problemi con nessuno di questi scenari.)

Git è all'incirca allo stesso modo. Sto lavorando fianco a fianco con un altro sviluppatore su un progetto, e ho solo cercato di selezionare uno dei suoi commit nella mia forcella. Si è rifiutato di lasciarmi perché ho modifiche non eseguite 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 mettere da parte le mie modifiche!

Se una persona dovesse trattare qualcosa di completamente innocuo con un'estrema cautela, la chiamerei una "fobia", una paura irrazionale che dovrebbe essere considerata un disturbo mentale. Ma Git e Mercurial sono stati progettati da due team diversi 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 modifiche non vincolanti? E se sì, perché il problema in questione sembra esistere solo su DVCSes?

version-control dvcs

posta Mason Wheeler 17.09.2015 - 01:22

fonte

2 risposte

Leggi altre domande sui tag version-control dvcs

In che misura le chiamate alle funzioni influiscono sulle prestazioni? Creazione di una buona affermazione di problema

score 4 · Answer 1

Nel mondo DVCS i commit sono economici e la cronologia è mutabile. Il WIP può essere "sporco", come vuoi: e non vedo alcun motivo contro "rilascia il mio stato corrente in changeset per la memorizzazione"
La cronologia SVN è lineare, pertanto, devi per unire le bozze con le modifiche da nuove revisioni. DVCS usa (a priori) DAG, e head addizionale (commit + pull + up) per la cronologia divergente è più sicuro, rispetto alla fusione di una directory di lavoro modificata con le modifiche esterne recuperate
Quando si passa (a qualche nodo ) WC modificato in Subversion, si elimina una fusione aggiuntiva potenziale (contrariamente a "commit to old" - "switch" - "Unisci 1 raggio di portata") ... e sappiamo: l'unione in SVN non è il lato perfetto dello strumento, mentre non è affatto un problema per DVCSes

Riprendi

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

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

score 1 · Answer 2

Quando si uniscono o si selezionano in git , si crea immediatamente un commit. L'operazione non è completa finché il commit non è finito e parte della cronologia.

Ora, che cosa accadrebbe se git ti permettesse di ignorare le modifiche non salvate nella tua directory di lavoro? Avresti un (più o meno) tempo difficile per distinguere tra le modifiche / conflitti di fusione di cui hai bisogno per l'unione / la selezione delle ciliegie e le modifiche che hai introdotto tu stesso. 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 ciò che devi fare è mettere da parte le tue modifiche non salvate prima dell'unione, e disassociarle in seguito. Si noti che nel flusso di lavoro

git stash
git pull
git stash pop

hai due (!) operazioni di unione. Uno che unisce l'ultimo commit con le modifiche in entrata e uno che unisce le modifiche non salvate con il commit di unione risultante. In questo modo, hai sempre bisogno di unire due elementi in uno solo, evitando la confusione che deriverebbe dal tentativo di unire tre elementi in uno in una singola operazione mentre cerchi di ignorare queste tre cose. Il git stash / git stash pop rende facile ed esplicito il fatto che stai ignorando le modifiche non salvate per l'unione.