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

204

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)

Tamás Szelei
źródło
21
Dziwne, nigdy nie słyszałem, że Mercurial był łatwiejszy. Znalazłem więcej dokumentacji dla Gita (być może percepcji), więc się tego nauczyłem.
Nic
16
Ponieważ został stworzony przez Linusa?
Job
124
Wkraczając tutaj na terytorium świętej wojny, odkryłem, że Mercurial jest łatwiejszy w użyciu niż Git, ponieważ jako użytkownik systemu Windows czułam się mile widziana przez Mercurial i traktowana przez Git jak dziwak i przegrany. Wiem, że jestem oprogramowaniem antropomorficznym i wiem, że oba systemy doskonale nadają się do użycia w systemie Windows, ale takie wrażenie wywierają na nich oboje.
Carson63000,
24
hginit.com
Svish
11
Zastanawiam się, ile osób użyłoby Gita, gdyby Github nie istniał lub nie miał tak wielu głośnych projektów?
Chris S

Odpowiedzi:

240

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.

TheLQ
źródło
6
Komentatorzy: komentarze mają na celu poszukiwanie wyjaśnień, a nie dłuższą dyskusję. Jeśli masz rozwiązanie, zostaw odpowiedź. Jeśli Twoje rozwiązanie jest już opublikowane, głosuj za nim. Jeśli chcesz omówić to pytanie z innymi, skorzystaj z czatu . Aby uzyskać więcej informacji, zobacz często zadawane pytania .
1
IntelliJ IDEA i Xcode 4 mają wspaniałą integrację z Git na swoich platformach i do codziennych zadań nigdy nie musisz używać wiersza poleceń.
4
Chciałbym dodać, że tortoiseGIT jest teraz znacznie lepszy, gdy chcesz używać GIT na Windowsie. Nadal masz do czynienia z kluczami SSL, a proces instalacji nie przebiega płynnie, ale po zakończeniu działa łatwo.
Arkh
2
Rozszerzenia Git Osobiście uważam, że nawigacja i praca z nimi jest o wiele łatwiejsza niż TortoiseHG w systemie Windows, i użyłem tylko 1 linii poleceń w git.
KallDrexx,
1
Jestem trochę zaskoczony tym stwierdzeniem: „MinGW nie jest wierszem poleceń systemu Windows i po prostu działa inaczej. To szalone, że to jedyny sposób pracy z Git”. Korzystam z instalacji msysgit i opcji 2, aby uruchomić z wiersza poleceń systemu Windows. To działa dobrze. Jest kilka rzeczy, które nie działają (jak daszek, znak kontynuacji linii w DOS), ale są alternatywy dla tych (jak tylda), które działają dobrze. Nie jestem entuzjastą wiersza poleceń (a przynajmniej nie byłem, zanim zacząłem uczyć się Git), ale używanie Git z wierszem poleceń jest naprawdę łatwe. Czy coś brakuje?
Kyralessa
80

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.

cyklop
źródło
73
Więc Mercurial ukrywa tylko zaawansowaną funkcjonalność, podczas gdy GIT ukrywa całą funkcjonalność ... ;-)
awe
4
Git ma mieć większą moc. Na przykład nie ma odpowiednika HEAD ~ 1 gita . Mercurial ma p (x), który rozciąga się na gałęzie, jak bezużyteczne. W Hg nie ma etapu. Wszystkie gałęzie muszą być popychane podczas pchania. Mercurial nie jest tak elastyczny, nawet ze wszystkimi wtyczkami, takimi jak histedit, półka i rebase. Linia poleceń Gita jest również lepsza, daje wskazówki dla użytkownika, mercurials nie. Jestem zmuszony do korzystania z tego nieco kalekiego DVCS w pracy i doszedłem do sytuacji, w których rtęci nie ma mocy, by robić to, co chcę.
Keyo
22
@Keyo: Mercurial ma ~, patrz resetowania . Nie ma obszaru przeciwstawnego, ale można go emulować za pomocą MQ, który jest o wiele potężniejszy. Naucz się korzystać z narzędzia zamiast trzymać się tego, co wiesz z git, to się opłaci.
Idan K
22
@Keyo: Nie musisz przepychać wszystkich gałęzi za pomocą Mercurial podczas pchania. Możesz przesunąć określoną gałąź ( hg push --branch BRANCH) lub do określonej wersji ( hg push --rev REV). Zobacz hg help pushwięcej opcji.
Regent
1
Do Twojej wiadomości można uzyskać znaczny podzbiór obszaru przemieszczania za pomocą rozszerzenia rekordu . OTOH, myślę, że przedłużenie półki (wzorowane na komendzie Baazara „półka” i blisko „skrytki git”) służy znacznie lepiej większości celów korzystania z obszaru przeciwności.
brandizzi
47

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.
Alex Miller
źródło
6
+1 za wzmiankę o indeksie; Myślę, że indeks i jego interakcje są rzeczą, która sprawia, że git trudniejsze do nauczenia niż rtęć.
Sean McMillan
18
hgOdpowiednik gitoddziałów faktycznie nazywa bookmarks. O ile mi wiadomo, hgoddziały nie mają odpowiednika w git.
Hank Gay
6
Jestem w tej samej sytuacji, z rtęcią w pracy i dupkiem w domu. Rozgałęzianie rtęci jest dla mnie raczej denerwujące, lubię mieć prywatne oddziały i naciskać je, kiedy chcę. Mercurial zmusza mnie do korzystania z półek lub dodatkowych repozytoriów. Numery wersji są głupie, daj mi skrót. Scena jest świetna w git, tęsknię za tym. Naprawdę brakuje mi mocy gita. Zrobiłem kilka rzeczy z niektórymi wtyczkami, ale rozgałęzienie naprawdę mnie denerwuje.
Keyo
6
@Keyo - Z mojego doświadczenia gitwynika , że rozgałęzienie jest podzbiorem hgrozgałęziania. W hgmożna mieć zarówno nazwane i nienazwane (topologiczne) gałęzie, a nawet może zarządzać oddziałów nienazwanych w taki sam sposób, jak gitza pomocą zakładek. Nigdy tak naprawdę nie widziałem sensu w strefie przeciwności. Wolałbym odłożyć na bok niechciane zmiany, a następnie upewnić się, że mój kod skompiluje i ukończy testy przed ich zatwierdzeniem. Następnie mogę odłożyć półkę i kontynuować. Poza tym „Massaging Hunks” Charlesa Baileya ( str. 90
Mark Booth
7
@Keyo: W Mercurial prywatne oddziały nazywane są „zakładkami”: aktualizacja do wersji root hg bookmark keyo-stuff, rób rzeczy hg commit, a potem w końcu hg push -B keyo-stuff. Jeśli nie lubisz numerów wersji, nie używaj ich; Myślę, że Mercurial zaakceptuje skrót gdziekolwiek akceptuje numer wersji. Muszę powiedzieć, że wasze komentarze krytykujące Mercurial za brak cech, które tak naprawdę okazały się ignoranckie i nieco agresywne; nie robisz wiele dobrego dla stereotypu użytkowników Git!
Tom Anderson
29

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.

Wieża
źródło
+1 za „mniej wtf / minutę” -1 za „to jest bardzo subiektywne”. To nie jest bardzo subiektywne ... Nie wiem, dlaczego ludzie nadal myślą, że różnice w interfejsie użytkownika są subiektywne. Jeśli wezmę mercurial i hash md5, nie argumentowałbyś, że niektórzy ludzie mogą znaleźć hash md5 bardziej intuicyjny niż oryginał, prawda? (Mam nadzieję, że nie). To samo dotyczy Gita. Git jest łatwiejszy niż rtęciowy tylko wtedy, gdy twoje doświadczenie z gitem jest znacznie bardziej istotne niż rtęciowe.
weberc2,
17

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.

pdr
źródło
7
Nie. Jest o wiele więcej kroków w przepływie pracy, abyś mógł nazwać to „inną składnią”. Musisz zrozumieć model, którym manipulujesz, i cały stan indeksu git, aby móc korzystać z Git. Mówienie SQL i Pascal to dwie różne składnie, ponieważ to samo byłoby równie błędne. Git to system wersjonowania systemu plików z funkcjami DVCS. Mercurial to DVCS, który nie wykonuje wszystkich operacji wersjonowania systemu plików, jakie wykonuje GIT, tylko podzbiór wymagany przez wszystkich użytkowników DVCS.
Warren P,
9

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.

Warren P
źródło
7

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
    
jammycakes
źródło
3
Właściwie wolę pomoc o długości 912 linii niż pomoc o długości 64.
Dysaster
10
Właściwie wolę interfejs użytkownika, który jest tak intuicyjny i bezproblemowy, że nie potrzebujesz pomocy.
jammycakes
2
Chcę zarówno GUI, jak i pomocy. :) To, co wydaje mi się intuicyjne, to bałagan dla kogoś innego.
Dysaster
1
Jasne, ale kiedy pomoc jest konieczna, powinna być łatwa do naśladowania.
jammycakes
3
Myślałem o nowej analogii; Git jest jak C ++ (przepraszam Linus!), A Mercurial jest jak Pascal. Co jest niejawne i można to zrobić tylko w Pascalu (lub Mercurial) tylko w jeden sposób, można to zrobić jawnie, dziewiętnaście różnych sposobów w C ++ (i Git). Niektórzy ludzie wolą elektronarzędzia z większą ilością przycisków i dźwigni, a Git jest tym.
Warren P
3

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

Zhehao Mao
źródło
11
Często w moim przepływie pracy automatyczne dodawanie nowych plików jest w rzeczywistości niepożądane. Wolę, aby działało to git commit -apo prostu dlatego, że ułatwia kontrolowanie tego, co działa i nie jest dodawane do danego zatwierdzenia. (Właściwie nie jest dla mnie niczym niezwykłym, aby każdemu z nich podawać indywidualne ścieżki, svn ciaby uniknąć dodawania niepowiązanego materiału do zatwierdzenia.)
greyfade
3
W porządku, ale wierzę, że hg cibez -Aflagi robi to git commit -a. Użyłem git dużo więcej niż hg, więc nie jestem w 100% pewien.
Zhehao Mao
Sprawdziłem hg ci== git commit -a.
Zhehao Mao
ale jeśli określisz określone pliki za pomocą hg commit, możesz uniknąć pobierania tych, których nie chcesz. W rzadkich przypadkach, w których chcę tej kontroli, uważam, że działa to dobrze.
Alex Miller
1
dlaczego miałbyś „dodawać”. a następnie „git commit -am”? Czy wszystko nie byłoby już dodane do indeksu?
jacobangel
3

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.

haziz
źródło