Perché Mercurial è considerato più facile di Git?

Quando guardo i confronti, mi sembra che ci potrebbe essere un mapping 1: 1 tra i loro set di funzionalità. Tuttavia, un'affermazione spesso citata è che "Mercurial è più facile". Qual è la base di questa affermazione? (se presente)

Caso in questione: diciamo che vuoi cambiare il nome utente in tutti i tuoi precedenti commit. Ho dovuto farlo più volte per vari motivi.

Versione Git

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Versione mercuriale:

autori.convert.list file:

<oldname>=<newname>

Riga di comando:

hg convert --authors authors.convert.list SOURCE DEST

Ora, quale sembra più facile da usare?

Nota: ho trascorso 2 anni lavorando esclusivamente con Git, quindi questo non è un rant "Lo odio, non l'ho preso in 2 secondi".

Per me è l'usabilità. Git è molto orientato a Linux con un modo linux di fare le cose. Ciò significa riga di comando, pagine man e capire da soli. Aveva una GUI molto scadente (nota: sto basando questo su msysGit da circa un anno fa), che sembrava solo mettermi sulla mia strada. Potrei a malapena usarlo

La riga di comando era peggio. Essendo un programma orientato a Linux, su Windows era molto difficile da usare. Invece di una porta nativa hanno semplicemente avvolto git con MinGW (Think cygwin), il che ha reso molto più difficile lavorare con esso. MinGW non è il prompt dei comandi di Windows e agisce solo diversamente. È assurdo che questo sia l'unico modo di lavorare con Git. Anche in Linux sembrava che l'unico modo fosse lavorare con la riga di comando diretta. Progetti come RabbitVCS hanno aiutato alcuni, ma non erano molto potenti.

L'approccio orientato alla riga di comando ed essere un programma linux ha significato che quasi tutte le guide howto, la documentazione di aiuto e le domande del forum / QA si basavano sull'esecuzione di comandi mostruosi come sopra. I comandi SCM di base (commit, pull, push) non sono così complessi, ma più e la complessità cresce in modo esponenziale.

Odio anche l'unico posto in cui molti utenti OSS git sembrano appendere: Github. Quando vai per la prima volta su una pagina di github, ti sbatte con tutto ciò che puoi eventualmente fare. Per me, una pagina git di progetti sembra caotica, spaventosa e eccessivamente potente. Anche la spiegazione di ciò che il progetto è, viene spinto verso il basso. Github fa davvero male alle persone che non hanno già un sito web completo già configurato. Anche il tracker dei problemi è terribile e confuso. Sovraccarico di funzionalità.

Anche gli utenti Git sembravano molto cult. Gli utenti Git sembrano essere sempre quelli che iniziano le "guerre sante" sulle quali DVCS è migliore, il che costringe quindi gli utenti di Mercurial a difendersi. Siti come http://whygitisbetterthanx.com/ mostrano arroganza e una mentalità quasi "Usa il mio software o muori". Molte volte sono andato in vari luoghi di aiuto solo per essere infiammato per non conoscere X, usare X in anticipo, usare Windows, ecc. È pazzesco.

Mercurial invece sembra andare verso un approccio più gentile. La loro home page sembra molto più amichevole per i nuovi utenti rispetto a quella di Git . In una semplice ricerca su Google il 5 ° risultato è TortoiseHg, un'interfaccia grafica molto bella per Mercurial. Il loro intero approccio sembra essere prima semplicità, potere dopo.

Con Mercurial non ho sciocchezze SSH (SSH è un inferno su Windows), non ho comandi stupidamente complessi, non ho un utente di culto che segue, non ho pazzia. Mercurial funziona e basta.

TortoiseHg fornisce un'interfaccia effettivamente utilizzabile (anche se ultimamente sembra in crescita) che fornisce funzionalità effettivamente utili. Le opzioni sono limitate a ciò di cui hai bisogno, rimuovendo il disordine e le opzioni che vengono utilizzate raramente. Fornisce anche molte impostazioni predefinite decenti

Mercurial, essendo molto amichevole con i nuovi arrivati, era molto facile da raccogliere. Anche alcuni degli argomenti più complessi come il diverso modello di ramificazione e la modifica della cronologia sono stati molto facili da seguire. Ho raccolto Mercurial in modo rapido e indolore.

Mercurial funziona anche la prima volta con poca configurazione. Su QUALSIASI sistema operativo posso semplicemente installare TortoiseHg e ottenere tutte le funzionalità che desidero (principalmente i comandi del menu contestuale) senza dover cercare diversi Guis. Manca anche l'installazione di SSH (metà delle guide là fuori dicono di usare Putty, Plink e Pagent mentre l'altra metà dice di usare ssh-keygen). Per i nuovi utenti, TortoiseHg richiede pochi minuti per l'installazione, mentre Git impiega da 30 minuti a un'ora con molti googling.

Infine hai i repository online. L'equivalente di Githubs è BitBucket, che presenta alcuni dei problemi che ho descritto sopra. Tuttavia c'è anche il codice di Google. Quando vado a un progetto Google Code , non ricevo un sovraccarico di funzionalità, ottengo un'interfaccia pulita e gradevole. Google Code è più una combinazione di repository / sito Web online, che aiuta davvero i progetti OSS che non hanno una configurazione del sito esistente. Mi sentirei molto a mio agio nell'utilizzare Google Code come sito Web dei miei progetti per un po 'di tempo, costruendo un sito Web solo quando assolutamente necessario. Anche il tracker dei problemi è potente, si adatta perfettamente al quasi inutile Issue Tracker di Github e alla mostruosità di Bugzilla .

Mercurial funziona solo, la prima volta, ogni volta. Git si mette sulla mia strada e mi fa solo arrabbiare più lo uso.

Git contro Mercurial

Mercurial è generalmente ritenuto più semplice e più facile da imparare di Git. A sua volta, c'è spesso la percezione che Git sia più flessibile e potente. Ciò è dovuto, in parte, perché Git tende a fornire più comandi di basso livello, ma anche in parte perché Mercurial predefinito tende a nascondere funzionalità avanzate , lasciando agli utenti la modifica del file di configurazione mercuriale per attivare le funzionalità avanzate che preferiscono. Ciò porta spesso alla percezione che funzionalità avanzate non sono disponibili in Mercurial.

Concetti di Git

Mercurial si è sempre focalizzato maggiormente sugli aspetti dell'interfaccia, che in origine rendeva più semplice l'apprendimento. Rispetto a Git, è necessaria una comprensione meno profonda per operare con Mercurial in modo utile. A lungo termine, tale incapsulamento ha dato a Mercurial il falso aspetto di essere meno potente e ricco di funzionalità di quanto non sia in realtà.

Contesto: utilizzo quotidianamente sia Mercurial (per lavoro) che Git (per progetti secondari e open source). Uso principalmente strumenti basati su testo con entrambi (non IDE) e sono su un Mac.

In generale, trovo Mercurial più facile da lavorare. Alcune cose che trovo rendono Mercurial più semplice:

1. Mancanza dell'indice L'indice è un potente strumento che abilita molte delle funzionalità di Git, ma è anche un livello aggiuntivo che aggiunge un passaggio a molte cose che faccio regolarmente. Il flusso di lavoro di Mercurial è più simile a qualcosa come svn.
2. Numeri di revisione anziché shas. Questa è una piccola cosa che trovo che rende molto più facile lavorare con i comandi giornalieri in Mercurial. È molto più semplice spingere alcuni numeri di revisione in testa durante un rebase, unire, ecc. Durante la scrittura di un comando piuttosto che fare lo stesso con shas anche abbreviati.
3. Filiali. L'approccio di Git alle filiali mediante la denominazione di commit è potente e sostanzialmente diverso rispetto ad altri sistemi di controllo delle versioni. Rende alcune cose molto più facili. Trovo che l'approccio di Mercurial corrisponda a svn pensando un po 'meglio e facilita la comprensione visiva della storia del ramo. Questa potrebbe essere solo una preferenza.

Questo è molto soggettivo e dipende da una persona all'altra, ma sì, vorrei che a qualcuno completamente nuovo di VCS o qualcuno proveniente da uno dei VCS "vecchia scuola", Mercurial sembrerà più facile.

Ad esempio, l'aggiunta di file, la non esistenza dell'indice in Hg, la facilità di tornare a qualche vecchia revisione e ramificazione da lì (basta aggiornare e impegnare) come alcuni degli esempi più "ovvi". Ora la maggior parte delle funzionalità di un sistema può essere emulata in un altro e viceversa, ma ciò richiede una certa conoscenza in Git, mentre in Mercurial le impostazioni predefinite (se mi permetti di chiamarle così) sono piuttosto "user friendly". Quelle piccole cose - l'interruttore qua e là, il comportamento non ovvio in un comando e così via ... queste cose si sommano e, alla fine, un sistema sembra più facile da usare rispetto all'altro.

Solo per completare la risposta; Uso git, ma quando raccomando un VCS per qualcuno che è "nuovo per loro", consiglio quasi sempre Mercurial. Ricordo, quando è arrivato per la prima volta nelle mie mani, mi è sembrato molto intuitivo. È la mia esperienza che Mercurial produce meno peso / minuto di Git.

Penso che sia così semplice: Mercurial ha una sintassi più familiare (in particolare per gli utenti SVN) ed è abbastanza ben documentato. Una volta che ti sarai abituato alla sintassi di Git, lo troverai facile da usare come qualsiasi altra cosa.

Le percezioni potrebbero cambiare nel tempo, su questo. Mercurial è molto ben progettato, così come Git. Mercurial sembra essere più facile da imparare (almeno lo era per me) e ci sono state difficoltà che ho incontrato in Git, per cui non ho parallelismi in Mercurial. Ho cercato di imparare Python e Ruby e sono andato più lontano, più velocemente con Python. Ciò non significa che Python sia sempre e ovunque migliore di Ruby, o anche che sia meglio per me. È proprio quello che ho imparato e bloccato. I programmatori spesso fanno guerre sante per preferenza personale. Anche altri esseri umani lo fanno.

Sono un utente mercuriale che cerca di mantenere una mentalità aperta su Git e ammetto liberamente che non è "diventato la mia nuova cosa preferita" nella stessa misura di Mercurial. Penso che Git sia davvero molto carino.

Un contro esempio per GIT / complessità mercuriale: il supporto Nice GIT è integrato in XCode, su Mac. XCode con Mercurial meno facile da usare di GIT.

La mia esperienza con GIT finora è stata che mi confondo e mi perdo e devo andare a consultare la documentazione più durante l'utilizzo. Credo che sia stata scritta molta documentazione, ma nulla che mi abbia permesso di "grok". In secondo luogo, posso modificare ed estendere facilmente Mercurial in Python, e poiché sono esperto in Python, e poiché chiunque potrebbe davvero imparare rapidamente Python, mi sembra un vantaggio. Conosco anche C e scrivo le estensioni Python in C, quindi suppongo che un giorno, se ne avessi bisogno, potrei facilmente scrivere un'estensione Git in C.

La facilità d'uso non è facile da quantificare. È lì e non penso che sia del tutto soggettivo, ma non abbiamo buone tecniche oggettive di misurazione. Quali sarebbero le unità per la facilità d'uso? Milli-iPod?

Non sono così partigiano da essere al 100% pro-mercuriale e al 100% anti-git. Mi sento più a mio agio su Mercurial in questo momento, su Windows e su Linux, e quando comincio a fare più lavoro su Mac, mi aspetto che proverò a rimanere con XCode + GIT.

Aggiornamento 2013: ora ho usato Mercurial AND GIT abbastanza a lungo per trovare alcune funzionalità che vorrei che avesse Git, come questa domanda sulle strategie di unione. Davvero Git è sorprendente, se difficile da imparare, e talvolta stranamente complesso.

Ci sono alcune cose che l'IMO probabilmente metterà in fuga Git dai nuovi utenti:

1. La cultura Git è più incentrata sulla riga di comando. Mentre entrambi gli strumenti tendono a concentrarsi troppo sulla riga di comando (come ho già detto più volte, le istruzioni della riga di comando possono essere potenti e più fluide, ma non sono una buona strategia di marketing ), questo è molto più il caso di Git. Mentre Mercurial ha uno strumento GUI standard di fatto in TortoiseHg, che è anche l'opzione di download predefinita per gli utenti Windows sulla homepage di Mercurial, Git ha diversi front-end GUI concorrenti (TortoiseGit, Git Extensions, gitk, ecc.) Che non sono ben pubblicizzati sul sito web Git, e che sono comunque tutti un pugno nell'occhio. (Testo nero su etichette rosse? Dai, TortoiseGit, puoi fare di meglio!) C'è anche un atteggiamento molto più pervasivo nella comunità Git secondo cui le persone che usano gli strumenti della GUI non sono sviluppatori di software adeguati.

2. Git ha diverse impostazioni predefinite che hanno perfettamente senso per gli utenti avanzati, ma sono probabilmente sorprendenti se non intimidatorie per i nuovi utenti. Ad esempio, è molto più aggressivo sull'automazione di attività come l'unione (ad esempio, git pull si unisce e si impegna automaticamente dove possibile). Esiste un caso di fusioni completamente automatizzate , ma la maggior parte degli utenti inesperti è terrorizzata dalla fusione e deve avere l'opportunità di acquisire fiducia nei propri strumenti prima di liberare la loro piena potenza dal loro codice sorgente.

3. Documentazione e complessità intrinseca:

   $ hg help log | wc -l
   64
   $ git help log | wc -l
   912
   

Una cosa che mi viene in mente è

git add .
git commit -am "message"

vs.

hg ci -Am "message"

git commit -anon aggiunge nuovi file creati hg ci -A, il che significa che qualcosa che richiede due comandi con git può essere fatto con un comando in Mercurial. Inoltre, "meno battitura" non significa necessariamente "più intuitivo".

Perchè è.

Git espone molto più del suo coraggio che mercuriale. Puoi tranquillamente usare mercurial in pochi minuti dalla raccolta, ma trovo che git sia ancora molto difficile da affrontare dopo un paio di mesi di lotta con esso (ho fatto molto poco negli ultimi due mesi oltre a cercare di imparare git ). Sto usando entrambi dalla riga di comando e principalmente su Linux, quindi questa non è solo una avversione per l'interfaccia della riga di comando.

Un semplice esempio sono i relativamente pochi flag e argomenti della riga di comando necessari per mercurial rispetto a git. Anche l'area di gestione temporanea e il comportamento del comando add in git aggiungono più complessità del necessario. Il trio di reset, checkout e ripristino e le loro molteplici permutazioni aggiunge un'enorme complessità, che era del tutto superflua quando si assiste alla natura semplice del ripristino e dell'aggiornamento su mercurial.

Concordo con il commento sopra anche su Hginit , che ha reso il mercurial molto più facile da comprendere. Ben scritto e molto facile da capire. Nessuna documentazione scritta per Git si avvicina. Io per primo, trovo la maggior parte di ciò che è scritto da Scott Chacone (che ha scritto da solo la maggior parte della documentazione / libri su Git) particolarmente confuso.