Dlaczego Mercurial jest uważany za łatwiejszy niż Git?

Patrząc na porównania, wydaje mi się, że może istnieć odwzorowanie 1: 1 między ich zestawami funkcji. Często cytowanym stwierdzeniem jest jednak to, że „Mercurial jest łatwiejszy”. Jaka jest podstawa tego stwierdzenia? (Jeśli w ogóle)

Przykład: powiedzmy, że chcesz zmienić nazwę użytkownika we wszystkich swoich poprzednich zatwierdzeniach. Musiałem to zrobić kilka razy z różnych powodów.

Wersja 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

Wersja Mercurial:

plik autorzy.convert.list:

<oldname>=<newname>

Wiersz poleceń:

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

Który z nich wygląda na łatwiejszy w użyciu?

Uwaga: spędziłem 2 lata pracując wyłącznie z Git, więc nie jest to stwierdzenie „Nienawidzę tego, nie dostałem go w 2 sekundy”.

Dla mnie to użyteczność. Git jest bardzo zorientowany na Linuksa z linuxowym sposobem robienia rzeczy. Oznacza to linię poleceń, strony podręcznika i samodzielne rozpracowanie. Miał bardzo kiepski GUI (uwaga: bazuję na msysGit sprzed około roku), który wydawał mi się po prostu przeszkadzać. Ledwo mogłem z tego skorzystać

Linia komend była gorsza. Jako program zorientowany na Linuksa, w systemie Windows był bardzo trudny w użyciu. Zamiast rodzimego portu po prostu otoczyli git MinGW (Think cygwin), co znacznie utrudniło pracę z nim. MinGW nie jest wierszem poleceń systemu Windows i po prostu działa inaczej. To szalone, że to jedyny sposób na pracę z Git. Nawet w Linuksie wydawało się, że jedynym sposobem jest praca z prostą linią poleceń. Projekty takie jak RabbitVCS pomogły niektórym, ale nie były bardzo potężne.

Podejście zorientowane na wiersze poleceń i program linuxowy oznaczały, że prawie wszystkie przewodniki instruktażowe, dokumentacja pomocy oraz pytania forum / QA polegały na uruchamianiu potwornych poleceń, jak wyżej. Podstawowe polecenia SCM (zatwierdzanie, wyciąganie, wypychanie) nie są tak skomplikowane, ale już bardziej, a złożoność rośnie wykładniczo.

Nienawidzę także jednego miejsca, w którym wielu użytkowników gita OSS kręci się wokół: Github. Gdy po raz pierwszy wejdziesz na stronę github, zaskoczy Cię ona wszystkim, co możesz zrobić. Dla mnie strona projektu git wygląda chaotycznie, przerażająco i jest zbyt potężna. Nawet wyjaśnienie, czym jest projekt, jest spychane na sam dół. Github naprawdę boli ludzi, którzy nie mają jeszcze pełnej konfiguracji witryny. Narzędzie do śledzenia problemów jest również okropne i mylące. Przeciążenie funkcji.

Użytkownicy Gita również byli bardzo kultowi. Wydaje się, że użytkownicy Git zawsze rozpoczynają „święte wojny”, nad którymi DVCS jest lepszy, co zmusza użytkowników Mercurial do obrony. Strony takie jak http://whygitisbetterthanx.com/ wykazują arogancję i mentalność prawie „używaj mojego oprogramowania lub giń”. Wiele razy chodziłem do różnych miejsc pomocy tylko po to, by mnie podpalić za to, że nie znałem X, wcześniej korzystałem z X, korzystałem z Windows itp. To szalone.

Z drugiej strony Mercurial wydaje się zmierzać w stronę bardziej przyjaznego podejścia. Ich własna strona główna wydaje się znacznie bardziej przyjazna dla nowych użytkowników niż Git . W prostym wyszukiwaniu Google piątym wynikiem jest TortoiseHg, bardzo ładne GUI dla Mercurial. Całe ich podejście wydaje się przede wszystkim prostotą, a później mocą.

Z Mercurialem nie mam bzdur SSH (SSH to piekło w systemie Windows), nie mam głupio skomplikowanych poleceń, nie śledzę kultowych użytkowników, nie mam szaleństwa. Mercurial po prostu działa.

TortoiseHg zapewnia rzeczywiście użyteczny interfejs (choć ostatnio wydaje się, że rośnie), który zapewnia naprawdę przydatne funkcje. Opcje są ograniczone do potrzebnych, usuwając bałagan i rzadko używane opcje. Zapewnia również wiele przyzwoitych ustawień domyślnych

Mercurial, będąc bardzo przyjaznym dla początkujących, był bardzo łatwy do zdobycia. Nawet niektóre bardziej złożone tematy, takie jak inny model rozgałęziania i edycja historii, były bardzo łatwe do naśladowania. Szybko i bezboleśnie podniosłem Mercurial.

Mercurial działa również po raz pierwszy przy niewielkiej konfiguracji. W DOWOLNYM systemie operacyjnym mogę po prostu zainstalować TortoiseHg i uzyskać wszystkie potrzebne funkcje (głównie polecenia menu kontekstowego) bez konieczności szukania różnych Guis. Brakuje również konfiguracji SSH (połowa przewodników mówi o używaniu Putty, Plink i Pagent, podczas gdy druga połowa mówi o używaniu ssh-keygen). Dla nowych użytkowników TortoiseHg zajmuje kilka minut, a Git zajmuje od 30 minut do godziny z dużą ilością googlingu.

Wreszcie masz repozytorium online. Odpowiednikiem Githubs jest BitBucket, który zawiera niektóre z problemów opisanych powyżej. Istnieje jednak kod Google. Kiedy idę do projektu Google Code , nie dostaję przeciążenia funkcji, otrzymuję ładny, czysty interfejs. Google Code to bardziej internetowa kombinacja repo / witryny, która naprawdę pomaga projektom OSS, które nie mają istniejącej konfiguracji witryny. Czułem się bardzo dobrze, korzystając z Google Code jako strony internetowej moich projektów, budując stronę internetową tylko wtedy, gdy jest to absolutnie konieczne. Jego narzędzie do śledzenia problemów jest również potężne, dobrze wpasowując się między prawie bezużyteczny narzędzie do śledzenia problemów Github a potwornością Bugzilli .

Mercurial działa po raz pierwszy za każdym razem. Git staje mi na drodze i tylko mnie gniewa, im częściej go używam.

Git kontra Mercurial

Ogólnie uważa się, że Mercurial jest prostszy i łatwiejszy do nauczenia niż Git. Z kolei często zdaje się, że Git jest bardziej elastyczny i potężny. Wynika to częściowo z tego, że Git ma tendencję do dostarczania większej liczby poleceń niskiego poziomu, ale także częściowo dlatego, że domyślny Mercurial ma tendencję do ukrywania zaawansowanych funkcji , pozostawiając użytkownikom edycję pliku konfiguracyjnego Mercurial, aby aktywować zaawansowane funkcje, które im się podobają. Często prowadzi to do przekonania, że ​​zaawansowane funkcje nie są dostępne w Mercurial.

Koncepcje Git

Mercurial zawsze koncentrował się bardziej na aspektach interfejsu, co początkowo ułatwiało jego naukę. W porównaniu z Git wymagane jest płytsze zrozumienie, aby użytkować Mercurial w użyteczny sposób. Na dłuższą metę takie kapsułkowanie nadało Mercurialowi fałszywy wygląd, że jest mniej potężny i wyróżnia się niż jest w rzeczywistości.

Kontekst: Używam zarówno Mercurial (do pracy), jak i Git (do pobocznych projektów i open source) na codzień. Korzystam głównie z narzędzi tekstowych z obu (nie IDE) i jestem na komputerze Mac.

Ogólnie rzecz biorąc, praca z Mercurialem jest łatwiejsza. Kilka rzeczy, które znajduję, sprawiają, że Mercurial jest łatwiejszy:

1. Brak indeksu. Indeks jest potężnym narzędziem umożliwiającym wiele funkcji Gita, ale jest także dodatkową warstwą, która dodaje krok do wielu rzeczy, które robię regularnie. Przepływ pracy Mercurial jest bardziej podobny do svn.
2. Numery wersji zamiast shas. To drobiazg, który według mnie sprawia, że ​​praca z poleceniami na co dzień w Mercurial jest o wiele łatwiejsza. O wiele łatwiej jest wcisnąć kilka numerów rewizji do głowy podczas tworzenia bazy, scalania itp. Podczas pisania polecenia, niż robić to samo z nawet skróconymi shas.
3. Gałęzie. Podejście Gita do gałęzi poprzez nazywanie zatwierdzeń jest potężne i zasadniczo różni się od innych systemów kontroli wersji. To sprawia, że ​​pewne rzeczy są znacznie łatwiejsze. Uważam, że podejście Mercurial pasuje do svn myślenia nieco lepszego i ułatwia wizualne zrozumienie historii branży. To może być tylko preferencja.

Jest to bardzo subiektywne i zależy od jednej osoby do drugiej, ale tak, poszedłbym do kogoś zupełnie nowego w VCS lub kogoś pochodzącego z jednego ze „starych szkolnych” VCS, Mercurial będzie wydawał się łatwiejszy.

Na przykład dodawanie plików, nieistnienie indeksu w Hg, łatwość powrotu do niektórych starych wersji i rozgałęzień stamtąd (wystarczy zaktualizować i zatwierdzić) jako jedne z najbardziej „oczywistych” przykładów. Teraz większość funkcji jednego systemu można emulować w innym i odwrotnie, ale to wymaga pewnej wiedzy na temat Git, podczas gdy w Mercurial wartości domyślne (jeśli pozwolisz mi je tak nazwać) są raczej „przyjazne dla użytkownika”. Te małe rzeczy - przełączanie tu i tam, nieoczywiste zachowanie w jednym poleceniu i tak dalej ... te rzeczy się sumują, a ostatecznie jeden system wydaje się łatwiejszy w użyciu niż drugi.

Tylko po to, żeby odpowiedź była kompletna; Używam git, ale kiedy polecam VCS komuś, kto jest dla niego „nowy”, prawie zawsze polecam Mercurial. Pamiętam, kiedy po raz pierwszy weszło mi w ręce, było bardzo intuicyjne. Z mojego doświadczenia wynika, że ​​Mercurial wytwarza mniej wtf / minutę niż Git.

Myślę, że to takie proste: Mercurial ma bardziej znaną składnię (szczególnie dla użytkowników SVN) i jest dość dobrze udokumentowany. Kiedy już przyzwyczaisz się do składni Git, przekonasz się, że jest równie łatwy w użyciu, jak wszystko inne.

Spostrzeżenia mogą zmieniać się z czasem. Mercurial jest bardzo dobrze zaprojektowany, podobnie jak Git. Wydaje się, że Mercurial jest łatwiejszy do nauczenia się (przynajmniej dla mnie), i były trudności, które napotkałem w Git, dla których nie mam analogii w Mercurial. Próbowałem nauczyć się języka Python i Ruby i dalej, szybciej z Pythonem. To nie znaczy, że Python jest zawsze i wszędzie lepszy niż Ruby, a nawet, że jest dla mnie lepszy. Właśnie tego się nauczyłem i utknąłem. Programiści często czynią święte wojny z osobistych preferencji. Inni ludzie też to robią.

Jestem użytkownikiem rtęci, który stara się zachować otwarty umysł na temat Git i swobodnie przyznam, że nie stało się to „moją nową ulubioną rzeczą” w takim samym stopniu, jak Mercurial. Myślę, że Git jest naprawdę naprawdę fajny.

Przeciwny przykład złożoności GIT / rtęci: Nicea GIT jest wbudowana w XCode na Macu. Mniej łatwy w użyciu XCode z Mercurial niż GIT.

Moje dotychczasowe doświadczenia z GIT polegają na tym, że jestem zagubiony i zagubiony i muszę korzystać z dokumentacji w trakcie korzystania. Uważam, że napisano wiele dokumentacji, ale nic, co nie pozwoliło mi jej „zrozumieć”. Po drugie, mogę łatwo modyfikować i rozszerzać Mercurial w Pythonie, a ponieważ jestem biegły w Pythonie i ponieważ każdy naprawdę mógł szybko nauczyć się Pythona, wydaje mi się to zaletą. Znam również C i piszę rozszerzenia Pythona w C, więc przypuszczam, że pewnego dnia, gdybym potrzebował, mógłbym łatwo napisać rozszerzenie Git w C.

Łatwość użycia nie jest rzeczą łatwą do oszacowania. Jest tam i nie sądzę, że jest to całkowicie subiektywne, ale nie mamy dobrych obiektywnych technik pomiaru. Jakie byłyby jednostki ułatwiające użytkowanie? Milli-iPody?

Nie jestem tak stronniczy, aby być w 100% pro-rtęciowy i w 100% przeciwny gitowi. Teraz czuję się bardziej komfortowo na Mercurial, na Windowsie i Linuksie, a kiedy zacznę robić więcej pracy na Macu, spodziewam się, że spróbuję trzymać się XCode + GIT.

Aktualizacja 2013: Używałem już Mercurial AND GIT wystarczająco długo, aby znaleźć pewne funkcje, które chciałbym mieć w Git, takie jak to pytanie o strategie scalania. Naprawdę Git jest niesamowity, choć trudny do nauczenia, a czasem irytująco złożony.

Jest kilka rzeczy, które IMO mogą zniechęcić nowych użytkowników do Git:

1. Kultura Git jest bardziej zorientowana na wiersze poleceń. Chociaż oba narzędzia zwykle zbyt mocno koncentrują się na linii poleceń (jak już kilkakrotnie mówiłem, instrukcje linii poleceń mogą być potężne i bardziej płynne, ale nie są dobrą strategią marketingową ), tak jest w przypadku Git. Podczas gdy Mercurial ma de facto standardowe narzędzie GUI w TortoiseHg, które jest nawet domyślną opcją pobierania dla użytkowników systemu Windows na stronie głównej Mercurial, Git ma kilka konkurencyjnych interfejsów GUI (TortoiseGit, rozszerzenia Git, gitk itp.), Które nie są dobrze reklamowane na stronie internetowej Git, które i tak są kompletnymi błędami. (Czarny tekst na czerwonych etykietach? No dalej, TortoiseGit, możesz zrobić to lepiej!) W społeczności Git istnieje również znacznie bardziej wszechobecne podejście, że ludzie używający narzędzi GUI nie są właściwymi programistami.

2. Git ma kilka domyślnych ustawień domyślnych, które są idealne dla zaawansowanych użytkowników, ale mogą być zaskakujące, jeśli nie zastraszające dla nowych użytkowników. Na przykład znacznie bardziej agresywne jest automatyzowanie zadań, takich jak scalanie (na przykład git pull automatycznie łączy i zatwierdza, jeśli to możliwe). Istnieją przypadki w pełni zautomatyzowanego łączenia, ale większość niedoświadczonych użytkowników jest przerażona połączeniem i należy dać im szansę na uzyskanie zaufania do swoich narzędzi przed uwolnieniem pełnej mocy kodu źródłowego.

3. Dokumentacja i nieodłączna złożoność:

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

Jedną rzeczą, o której mogę myśleć, jest

git add .
git commit -am "message"

vs.

hg ci -Am "message"

git commit -anie dodaje nowo utworzonych plików, hg ci -Aoznacza to, że coś, co wymaga dwóch poleceń za pomocą git, można wykonać za pomocą jednego polecenia w Mercurial. Z drugiej strony „mniej pisania” niekoniecznie oznacza „bardziej przyjazny dla użytkownika”.

Ponieważ to jest.

Git ujawnia znacznie więcej jego odwagi niż rtęci. Z radością możesz użyć merkurialu w ciągu kilku minut od jego podniesienia, ale nadal mam trudności z poradzeniem sobie z gitem po kilku miesiącach zmagania się z nim (w ciągu ostatnich kilku miesięcy niewiele zrobiłem poza próbą nauczenia się git ). Używam zarówno z wiersza poleceń, jak i głównie w systemie Linux, więc nie jest to tylko awersja do interfejsu wiersza poleceń.

Jednym prostym przykładem jest stosunkowo niewiele flag i argumentów wiersza poleceń potrzebnych do mercurial w porównaniu do git. Obszar przemieszczania i zachowanie polecenia add w git również zwiększa złożoność, niż jest to konieczne. Trio resetowania, kasowania i przywracania oraz ich wielokrotne permutacje dodają ogromną złożoność, co było zupełnie niepotrzebne, gdy zobaczysz prostą naturę przywracania i aktualizacji na rtęci.

Zgadzam się z powyższym komentarzem również o Hginicie , który zdecydowanie ułatwił zrozumienie merkurialu. Dobrze napisany i bardzo łatwy do zrozumienia. Żadna dokumentacja napisana dla git nie jest bliska. Po pierwsze, większość tego, co napisał Scott Chacone (który samodzielnie napisał większość dokumentacji / książek o git) jest szczególnie myląca.