Perché Mercurial è considerato più facile di Git?


204

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)


21
Strano, non ho mai sentito Mercurial più facile. Ho trovato più documentazione per Git (potrebbe essere stata una percezione), quindi l'ho imparato.
Nic,

16
Perché è stato realizzato da Linus?
Giobbe

124
Andando nel territorio della guerra santa qui, ma ho trovato Mercurial più facile da usare di Git perché, come utente di Windows, mi sono sentito accolto da Mercurial e trattato come un mostro e un perdente da Git. So di essere un software antropomorfizzante, e so che entrambi sono perfettamente in grado di essere usati bene sotto Windows, ma questa è l'impressione emessa da loro due.
Carson63000,


11
Mi chiedo quante persone userebbero Git se Github non esistesse o non avesse avuto così tanti progetti di alto profilo?
Chris S,

Risposte:


240

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.


6
Commentatori: i commenti hanno lo scopo di cercare chiarimenti, non di discussioni estese. Se hai una soluzione, lascia una risposta. Se la tua soluzione è già stata pubblicata, ti preghiamo di votarla. Se desideri discutere questa domanda con altri, utilizza la chat . Vedi le FAQ per maggiori informazioni.

1
IntelliJ IDEA e Xcode 4 hanno una meravigliosa integrazione con Git sulle rispettive piattaforme e per le attività quotidiane non è mai necessario utilizzare la riga di comando.

4
Vorrei aggiungere che tortoiseGIT è molto meglio ora quando vuoi usare GIT su Windows. Devi ancora avere a che fare con le chiavi SSL e il processo di installazione non è semplice, ma quando fatto funziona facilmente.
Arkh,

2
Estensioni di Git Personalmente trovo molto più facile navigare e lavorare con TortoiseHG su Windows, e ho usato solo 1 riga di comando in assoluto con Git.
KallDrexx,

1
Sono un po 'sconcertato da questa riga: "MinGW non è il prompt dei comandi di Windows e si comporta in modo diverso. È assurdo che questo sia l'unico modo di lavorare con Git." Uso l'installazione di msysgit e l'opzione 2, per eseguire dalla riga di comando di Windows. Funziona bene Ci sono alcune cose che non funzionano (come il punto di inserimento, un carattere di continuazione della riga in DOS) ma ci sono alternative a quelle (come la tilde) che funzionano bene. Non sono un appassionato di riga di comando (o almeno non lo ero prima di iniziare a imparare Git) ma usare Git con la riga di comando è davvero semplice. Mi sto perdendo qualcosa?
Kyralessa,

80

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à.


73
Quindi Mercurial nasconde solo le funzionalità avanzate, mentre GIT nasconde tutte le funzionalità ... ;-)
timore re

4
Git non hanno più potere. Ad esempio non esiste un equivalente di HEAD ~ 1 di git . Mercurial ha p (x) che si estende attraverso i rami, quanto inutile. Non c'è palcoscenico in Hg. Tutti i rami devono essere spinti quando si spinge. Mercurial non è altrettanto flessibile, anche con tutti i plugin come histedit, shelf e rebase. Anche la riga di comando di Git è migliore, dà suggerimenti all'utente, i mercuriali no. Sono costretto a usare questo DVCS leggermente paralizzato al lavoro e sono entrato in situazioni in cui mercurial non ha il potere di fare quello che voglio.
Keyo,

22
@Keyo: Mercurial ha ~, vedi revsets . Non ha un'area di gestione temporanea, ma puoi emularla con MQ, che è molto più potente. Impara a usare lo strumento piuttosto che attenersi a ciò che sai da Git, pagherà.
Idan K,

22
@Keyo: non devi spingere tutti i rami con Mercurial quando spingi. È possibile eseguire il push di un ramo specifico ( hg push --branch BRANCH) o fino a una revisione specifica ( hg push --rev REV). Si prega di vedere hg help pushper ulteriori opzioni.
Reggente

1
Cordiali saluti, è possibile ottenere un considerevole sottoinsieme dell'area di gestione temporanea utilizzando l' estensione del record . OTOH, penso che l' estensione di shelve (modellata sul comando "shelve" di Baazar e vicino a "git stash") serva molto meglio la maggior parte degli scopi dell'uso dell'area di staging.
brandizzi

47

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.

6
+1 per menzionare l'indice; Penso che l'indice e le sue interazioni siano la cosa che rende il git più difficile da imparare rispetto al mercuriale.
Sean McMillan,

18
L' hgequivalente ai gitrami viene effettivamente chiamato bookmarks. Per quanto ne so, i hgrami non hanno un equivalente in git.
Hank Gay,

6
Sono nella stessa situazione, con Mercurial al lavoro e git a casa. La ramificazione mercuriale è piuttosto fastidiosa per me, mi piace avere filiali private e spingerle quando mi piace. Mercurial mi costringe a usare scaffali o repository aggiuntivi. I numeri di revisione sono sciocchi, dammi l'hash. Il palco è fantastico, mi manca questo. Mi manca davvero il potere di Git. Ho fatto alcune cose con alcuni plugin, ma la ramificazione mi dà davvero fastidio.
Keyo,

6
@Keyo - Nella mia esperienza, la gitramificazione è un sottoinsieme di hgramificazione. In hgpuoi avere rami sia nominati che senza nome (topologici) e puoi persino gestire rami senza nome allo stesso modo gitdell'uso dei segnalibri. Non ho mai veramente visto il punto nell'area della messa in scena. Preferirei di gran lunga accantonare le modifiche indesiderate e quindi assicurarmi che il mio codice si compili e completi i test prima di eseguirlo. Posso quindi annullare l'accantonamento e continuare. Inoltre, "Massaging Hunks" (p90 +) di Charles Bailey mi spaventa * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
Mark Booth,

7
@Keyo: In Mercurial, le filiali private sono chiamate "segnalibri": esegui l'aggiornamento alla revisione principale, esegui le hg bookmark keyo-stuffoperazioni hg commite infine hg push -B keyo-stuff. Se non ti piacciono i numeri di revisione, non usarli; Mercurial accetterà un hash ovunque accetti un numero di revisione, credo. Devo dire che i tuoi commenti colpiscono Mercurial per la mancanza di funzionalità che in effetti si sono rivelati ignoranti e un po 'aggressivi; non stai facendo molto bene allo stereotipo degli utenti Git!
Tom Anderson,

29

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.


+1 per "meno peso / minuto" -1 per "questo è molto soggettivo". Non è molto soggettivo ... Non so perché la gente pensi ancora che le differenze dell'interfaccia utente siano soggettive. Se prendo i suoi comandi mercurial e md5 hash, non faresti l'argomento che alcune persone potrebbero trovare un hash md5 più intuitivo dell'originale, vero? (Spero di no). Lo stesso vale per Git. Git è più semplice di Mercurial se la tua esperienza con Git è considerevolmente più sostanziale di Mercurial.
weberc2,

17

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.


7
No. Ci sono troppi passaggi del flusso di lavoro per poterlo chiamare semplicemente "sintassi diversa". Devi usare il modello sottostante che stai manipolando, e tutto lo stato dell'indice git, per usare Git. Dire che SQL e Pascal sono due diverse sintassi per la stessa cosa sarebbe ugualmente sbagliato. Git è un sistema di controllo delle versioni del file system con funzionalità DVCS. Mercurial è un DVCS che non esegue tutte le operazioni di versioning del contenuto del file system GIT, ma solo il sottoinsieme che tutti gli utenti DVCS richiedono.
Warren P,

9

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.


7

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
    

3
In realtà, preferisco un aiuto lungo 912 linee a un aiuto che è 64.
Disastro

10
In realtà, preferisco un'interfaccia utente così intuitiva e senza interruzioni da non aver bisogno di aiuto in primo luogo.
Jammycakes,

2
Voglio sia la GUI sia l'aiuto. :) Ciò che mi sembra intuitivo è un casino per qualcun altro.
Disastro

1
Certo, ma quando è necessario un aiuto, dovrebbe essere facile da seguire.
Jammycakes,

3
Ho pensato a una nuova analogia; Git è come C ++ (scusate Linus!) E Mercurial è come Pascal. Ciò che è implicito e può essere fatto solo in un modo in Pascal (o Mercurial) può essere fatto esplicitamente, diciannove modi diversi in C ++ (e Git). Alcune persone preferiscono i powertools con più pulsanti e leve, e Git è quello.
Warren P

3

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".


11
Trovo spesso che nel mio flusso di lavoro, l'aggiunta automatica di nuovi file sia effettivamente indesiderabile. Sono arrivato a preferire il modo in cui git commit -afunziona semplicemente perché rende più semplice controllare cosa fa e non viene aggiunto per un determinato commit. (In realtà non è insolito per me specificare percorsi individuali per ognuno svn ciper evitare di aggiungere materiale non correlato a un commit.)
Greyfade,

3
Abbastanza giusto, ma credo che hg cisenza la -Abandiera faccia l'equivalente di git commit -a. Ho usato git molto più di hg, quindi non ne sono sicuro al 100%.
Zhehao Mao,

Ho controllato, hg ci== git commit -a.
Zhehao Mao,

ma se specifichi file specifici con hg commit, puoi evitare di inserire quelli che non vuoi. Nei rari casi in cui desidero questo controllo, trovo che funzioni bene.
Alex Miller,

1
perché dovresti "aggiungere git". e poi "git commit -am"? Non sarebbe già tutto aggiunto all'indice?
jacobangel,

3

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.