Git è progettato male?

No, Git non è progettato male. I dati effettivi che memorizza sono quasi perfetti e hanno solo due errori minori: l'uso di SHA-1 che è ormai noto per consentire la creazione di una collisione intenzionale di hash, e il fatto che la profondità totale della storia non è memorizzata negli oggetti di commit. Memorizzare la profondità non è in realtà strettamente necessario perché si può sempre calcolare dai dati disponibili, ma questo deve essere ricalcolato da tutte le parti ed è sempre statico, quindi sarebbe meglio averlo incluso nella struttura dei dati. Avrebbe avuto bisogno solo di 4 byte aggiuntivi per oggetto di commit e avrebbe ridotto molto l'uso della CPU su tutto l'uso di git. Alcune persone sosterrebbero anche che git dovrebbe consentire la memorizzazione dei timestamp per tutti i file nel commit separati dai timestamp di commit, il che richiederebbe la modifica degli oggetti dell'albero nell'archivio git. E i commit potrebbero supportare il salvataggio dei riferimenti alle vecchie versioni di ogni dato commit per permettere la visualizzazione delle cronologie di rebase se necessario. Questi cambiamenti permetterebbero a git di supportare alcune caratteristiche che attualmente non può avere.

L'uso di SHA-1 è problematico non solo per nominare i commit ma i tag firmati di git usano identificatori SHA-1 come contenuto dei dati firmati per la punta del DAG per firmare digitalmente un commit o un tag. Finché SHA-1 non ha un "attacco preimage noto", questo non è in realtà un problema, ma passare a un hash più forte ora renderebbe l'uso dei tag firmati più resiliente verso attacchi futuri. Si noti che anche MD5 non ha ancora un attacco noto di preimage anche se creare collisioni per MD5 è oggi considerato facile.

Tutto il resto dei problemi spesso percepiti è in realtà il risultato di git che ha il 100% di compatibilità all'indietro. Ogni piccola decisione strana che abbiano mai preso nell'interfaccia utente visibile è stata conservata per sempre. Tuttavia, questa è stata una decisione attiva che hanno preso perché gli sviluppatori di git hanno pensato che non rompere alcun flusso di lavoro esistente è più importante che avere ad esempio flag coerenti per tutti i comandi. Questo non dice che git è stato progettato male, ma che gli sviluppatori hanno considerato la compatibilità all'indietro più importante della facilità di apprendimento di git per i nuovi utenti. La tua preferenza personale come nuovo utente potrebbe essere diversa. Tuttavia, per gli utenti esperti, non rompere mai l'interfaccia utente quando si aggiorna git è una benedizione - si ottengono sempre e solo nuove funzionalità e correzioni di bug e non c'è motivo di continuare ad usare la vecchia versione di git quando è disponibile una versione più recente. E non si può avere entrambe le cose (cioè, sistemare la vecchia e strana interfaccia utente e non rompere la retrocompatibilità al 100%) quindi selezionare quale strada si vuole percorrere è ovviamente una decisione di design.

C'è stato qualche sforzo per creare concetti più facili da capire come spiegare index come "staging area" (simile ai dock del mondo reale) e supportare nuovi comandi come "git stage" invece di "git add" per aggiungere roba alla staging area (attualmente chiamata "index" in git). Tuttavia, questo è stato aggiunto troppo tardi nel processo e anche ai principianti viene ancora detto "git add" invece di "git stage", anche se quest'ultimo potrebbe essere più facile da capire. Credo che sia perché le persone che insegnano ai principianti conoscono solo la vecchia interfaccia.

Inoltre, git ha così tante caratteristiche che capirle tutte è difficile. Ditemi che git rebase -i è difficile da usare e vi chiederò come fareste la stessa azione con svn o mercurial o perforce?

Il design di git è il migliore che possa esistere? Ovviamente no. Ma aggiustare le decisioni di design originali romperebbe la compatibilità all'indietro. Immagina di fare tutto il lavoro per correggere quei due piccoli errori nella struttura dei dati e reimplementare tutte le caratteristiche con un'interfaccia utente leggermente diversa; buona fortuna nel convincere il mondo intero a passare al tuo nuovo sistema di controllo della versione che è solo marginalmente migliore e non è retrocompatibile con i tuoi progetti esistenti.