Git i Mercurial-porównanie i kontrast

Zastrzeżenie: używam Gita, śledzę rozwój Gita na liście dyskusyjnej gita, a nawet trochę wrzucam do Gita (głównie gitweb). Znam Mercurial z Dokumentacji i trochę z dyskusji na kanale # revctrl IRC na FreeNode.

dzięki wszystkim osobom na kanale IRC # mercurial, które zapewniły pomoc o Mercurial dla tego writeup

Podsumowanie

_{tutaj byłoby miło mieć jakąś składnię do tabeli, coś jak w phpmarkdown / MultiMarkdown / maruku rozszerzenie Markdown}

• struktura repozytorium: Mercurial nie pozwala na łączenie Octopusa (z więcej niż dwoma rodzicami), ani na oznaczanie obiektów niezwiązanych z zatwierdzeniem.
• Tagi: Mercurial używa wersjonowanego pliku .hgtags ze specjalnymi regułami dla znaczników per-repozytorium, a także obsługuje lokalne tagi w .hg/localtags; w Git znaczniki są refami rezydującymi w refs/tags/ przestrzeni nazw i domyślnie są automatycznie śledzone podczas pobierania i wymagają wyraźne pchanie.
• Branches: W Mercurial basic workflow opiera się na anonimowych głowach; Git używa lekkich nazwanych gałęzi i posiada specjalny rodzaj gałęzi (remote-tracking branches), które podążają za gałęziami w zdalnym repozytorium.
• nazewnictwo i zakresy rewizji: Mercurial dostarcza numery rewizji , lokalne do repozytorium i bazuje na względnych rewizjach (licząc od końcówki, tj. bieżącej gałęzi) i zakresach rewizji na tym Git udostępnia sposób, aby odnosić się do rewizji w odniesieniu do końcówki gałęzi, a zakresy rewizji są topologiczne (oparte na wykresie rewizji)
• Mercurial używa rename tracking , podczas gdy Git używa rename detection do obsługi zmiany nazw plików
• Sieć: Mercurial obsługuje protokoły SSH i HTTP "smart "oraz statyczny protokół HTTP; nowoczesny Git obsługuje protokoły SSH, HTTP i GIT" smart "oraz protokół HTTP(S)" dumb". Oba mają obsługa plików wiązek do transportu off-line.
• Mercurial używa rozszerzeń (wtyczek) i ustalonego API; Git ma skryptowalność i ustalone formaty.

Jest kilka rzeczy, które różnią się Mercurial od Gita, ale są inne rzeczy, które czynią je podobnymi. Oba projekty pożyczają od siebie pomysły. Na przykład hg bisect komenda w Mercurial (dawniej bisect extension) została zainspirowana git bisect komenda w Git, podczas gdy idea z git bundle został zainspirowany hg bundle.

Struktura repozytorium, przechowywanie wersji

W Git istnieją cztery typy obiektów w bazie danych obiektów: blob obiekty, które zawierają zawartość pliku, hierarchicznedrzewo obiekty, które przechowują strukturę katalogów, w tym nazwy plików i odpowiednie części uprawnień do plików (uprawnienia wykonywalne dla plików, będące dowiązaniem symbolicznym), commit obiekt, który zawiera informacje o autorstwie, wskaźnik do migawki stanu plików. repozytorium podczas rewizji reprezentowane przez commit (poprzez obiekt drzewa w górnym katalogu projektu) i odniesienia do zerowych lub więcej nadrzędnych commitów oraz znacznik obiektów, które odwołują się do innych obiektów i mogą być podpisywane przy użyciu PGP / GPG.

Git używa dwóch sposobów przechowywania obiektów: loose format, w którym każdy obiekt jest przechowywany w osobnym pliku (pliki te są zapisywane raz i nigdy nie modyfikowane), oraz packed format, w którym wiele obiektów jest przechowywanych w formacie delta-skompresowanym pojedynczy plik. Atomiczność operacji wynika z faktu, że odniesienie do nowego obiektu jest zapisywane (atomicznie, za pomocą create + rename trick) po zapisaniu obiektu.

Repozytoria Git wymagają okresowej konserwacji przy użyciu git gc (w celu zmniejszenia miejsca na dysku i poprawy wydajności), chociaż obecnie Git robi to automatycznie. (Ta metoda zapewnia lepszą kompresję repozytoriów.)

Mercurial (o ile to Rozumiem) przechowuje historię pliku w filelog (myślę, że razem z dodatkowymi metadanymi, takimi jak zmiana nazwy śledzenia i niektóre informacje pomocnicze); używa płaskiej struktury o nazwie manifest do przechowywania struktury katalogów, oraz struktury o nazwie changelog, która przechowuje informacje o zestawach zmian (rewizjach), w tym komunikat commit i zero, jeden lub dwóch rodziców.

Mercurial używa transaction journal do zapewnienia atomiczności operacji i polega na obcinaniu plików do czyszczenia po niepowodzeniu lub przerwana operacja. Revlogi są tylko dopisywane.

Patrząc na strukturę repozytorium w Git kontra w Mercurial, widać, że Git jest bardziej obiektową bazą danych( lub systemem plików adresowanym do zawartości), a Mercurial bardziej tradycyjną relacyjną bazą danych o stałych polach.

Różnice:
^{w Git drzewo obiekty tworzą hierarchiczną strukturę; w Mercurial manifest plik jest płaską strukturą. W Git blob obiekt przechowuje jedna wersja zawartości pliku; w Mercurial filelog przechowuje całą historię pojedynczego pliku (jeśli nie weźmiemy pod uwagę tutaj żadnych komplikacji ze zmianą nazw). Oznacza to, że istnieją różne obszary operacji, w których Git byłby szybszy niż Mercurial, wszystkie inne rzeczy uważane za równe (takie jak scalanie lub Pokazywanie historii projektu), oraz obszary, w których Mercurial byłby szybszy niż Git (takie jak nakładanie łat lub Pokazywanie historia pojedynczego pliku). ten problem może nie być ważny dla użytkownika końcowego.}

Ze względu na strukturę ze stałym rekordem struktury changelog struktury Mercurial, commity w Mercurial mogą mieć tylko maksymalnie dwóch rodziców; commity w Git mogą mieć więcej niż dwóch rodziców (tzw. "Octopus merge"). Chociaż można (teoretycznie) zastąpić Octopus merge serią dwu-rodzicielskich połączeń, może to spowodować komplikacje podczas konwersji między Mercurial i Git repozytoria.

Z tego co wiem Mercurial nie ma odpowiedników tagów z przypisami (tag objects) z Gita. Szczególnym przypadkiem znaczników z adnotacjami są signed tags (z podpisem PGP / GPG); odpowiednik w Mercurial może być wykonany za pomocą GpgExtension , które rozszerzenie jest dystrybuowane wraz z Mercurial. Nie możesz tagować obiektu non-commit W Mercurial, tak jak możesz w Git, ale to nie jest zbyt ważne, jak sądzę (niektóre repozytoria git używają tagged blob do dystrybucji publicznego klucza PGP do weryfikacji podpisanych tagów).

Odniesienia: gałęzie i znaczniki

W Git odwołania (gałęzie, gałęzie zdalnego śledzenia i znaczniki) znajdują się poza dag commitów (tak jak powinny). Referencje w refs/heads/ namespace (lokalne gałęzie) wskazują na commity i są zwykle aktualizowane przez "git commit"; wskazują na końcówkę (głowę) gałęzi, dlatego taka nazwa. Odwołania w refs/remotes/<remotename>/ przestrzeni nazw (zdalnie śledzące gałęzie) punkt aby zatwierdzić, postępuj zgodnie z gałęziami w zdalnym repozytorium <remotename> i są aktualizowane przez" git fetch " lub odpowiednik. Odniesienia w przestrzeni nazw refs/tags/ (znaczniki ) wskazują zwykle na commity (lekkie znaczniki) lub obiekty znaczników (znaczniki opatrzone adnotacją i podpisane) i nie mają na celu ich zmiany.

Tagi

W Mercurial możesz nadać trwałą nazwę revision używając znacznika ; znaczniki są przechowywane podobnie jak wzorce ignorowania. Oznacza to, że globalnie widoczne znaczniki są przechowywane w revision-controlled .hgtags plik w repozytorium. Ma to dwie konsekwencje: po pierwsze, Mercurial musi użyć specjalnych reguł dla tego pliku, aby uzyskać aktualną listę wszystkich tagów i zaktualizować taki plik (np. czyta ostatnio zatwierdzoną wersję pliku, a nie aktualnie sprawdzoną wersję); po drugie, musisz zatwierdzić zmiany w tym pliku, aby nowy tag był widoczny dla innych użytkowników / innych repozytoriów (o ile to Rozumiem).

Mercurial obsługuje również lokalne tagi, przechowywane w przypadku, gdy nie są widoczne dla innych (i oczywiście nie są zbywalne)

W Git znaczniki są stałymi (stałymi) nazwami odwołań do innych obiektów (zazwyczaj znaczników, które z kolei wskazują na commity) przechowywanymi w refs/tags/ przestrzeni nazw. Domyślnie podczas pobierania lub wypychania zestawu wersji, git automatycznie pobiera lub wypycha znaczniki, które wskazują na pobranie lub wypchnięcie wersji. Niemniej jednak możesz kontrolować w pewnym stopniu które znaczniki są pobierane lub pchnięty.

Git traktuje lekkie znaczniki (wskazujące bezpośrednio na commity) i znaczniki adnotacji (wskazujące na obiekty tagów, które zawierają wiadomość tagów, która opcjonalnie zawiera sygnaturę PGP, która z kolei wskazuje na commity) nieco inaczej, na przykład domyślnie uwzględnia tylko znaczniki adnotacji podczas opisywania commitów za pomocą "Git describe".

Git nie ma ścisłego odpowiednika lokalnych tagów w Mercurial. Niemniej jednak najlepsze praktyki git zalecają ustawienie oddzielnego publicznego bare repozytorium, do którego wypychasz gotowe zmiany i z którego inni klonują i pobierają. Oznacza to, że znaczniki (i gałęzie), których nie wypychasz, są prywatne w Twoim repozytorium. Z drugiej strony można również użyć przestrzeni nazw innej niż heads, remotes lub tags, na przykład local-tags dla tagów lokalnych.

^{osobista opinia: moim zdaniem znaczniki powinny znajdować się poza grafem rewizji, ponieważ są do niego zewnętrzne (są wskaźnikami do wykresu rewizji). Tagi powinny być nie-wersjonowane, ale zbywalne. Wybór mercuriala polegający na użyciu mechanizmu podobnego do tego, który ignoruje pliki, oznacza, że musi on albo traktować .hgtags specjalnie (plik w drzewie jest przekazywalny, ale zwykły jest wersjonowany), albo mieć tagi, które są tylko lokalne (.hg/localtags nie jest wersjonowany, ale nie można go przekazać).}

Gałęzie

W Git lokalna gałąź (branch tip, lub branch head) jest nazwanym odniesieniem do commita, w którym można tworzyć nowe commity. Branch może również oznaczać aktywna linia rozwoju, czyli wszystkie commity osiągalne z gałęzi. Lokalne gałęzie znajdują się w przestrzeni nazw refs/heads/, więc np. w pełni kwalifikowana nazwa gałęzi 'master' to 'refs/heads / master'.

Bieżąca gałąź w Git (czyli gałąź sprawdzona i gałąź, w której pojawi się nowy commit) to gałąź, do której odwołuje się HEAD ref. Można mieć głowę wskazującą bezpośrednio na commit, a nie jako symboliczne odniesienie; ta sytuacja bycia na anonimowej, nienazwanej gałęzi nazywa się detergent HEAD ("Git branch" pokazuje, że jesteś na '(no branch)').

W Mercurialu są anonimowe gałęzie (odgałęzienia) i można używać zakładek (poprzez rozszerzenie zakładek ). W przeciwieństwie do wersji 1.6 nie można było przenosić tych nazw za pomocą Mercurial. Możesz użyć rsync lub scp, aby skopiować plik .hg/bookmarks do zdalnego repozytorium. Możesz również użyć hg id -r <bookmark> <url>, aby uzyskać identyfikator wersji bieżącej końcówki zakładki.

Od 1.6 zakładki mogą być pchane/ciągnięte. Na stronie BookmarksExtension znajduje się sekcja na temat pracy ze zdalnymi repozytoriami. Istnieje różnica w tym, że w Mercurial nazwy zakładek są globalne , podczas gdy definicja 'remote' w Git opisuje również mapowanie nazw gałęzi Z nazw zdalnego repozytorium na nazwy lokalnych gałęzi zdalnego śledzenia; na przykład refs/heads/*:refs/remotes/origin/* mapowanie oznacza, że można znaleźć Stan' master ' gałęzi ('refs / heads / master') w zdalnym repozytorium w gałęzi' origin/master ' ('refs / remotes/origin / master').

Mercurial ma również tak zwane nazwane gałęzie, gdzie nazwa gałęzi jest osadzona W commicie (w zestawie zmian). Taka nazwa jest globalna(przenoszona na fetch). Nazwy tych gałęzi są trwale zapisywane jako część metadanych changeset\u2019s. Dzięki nowoczesnemu Mercurial możesz zamknąć "named branch" i zatrzymać nagrywanie nazwy gałęzi. W tym końcówki mechanizmu gałęzi są obliczane w locie.

Mercurial ' s "nazwane gałęzie" powinny moim zdaniem być nazywane etykiety commit zamiast tego, ponieważ jest to, czym są. Istnieją sytuacje, w których "named branch" może mieć wiele końcówek (multiple childless commits), a także może składać się z kilku oddzielnych części grafu rewizji.

Nie ma odpowiednika tych Mercurial "embedded branches" w Git; ponadto filozofia Git jest taka, że podczas gdy można powiedzieć, że branch zawiera jakiś commit, nie oznacza to, że commit należy do jakiejś gałęzi.

Zauważ, że dokumentacja Mercurial nadal proponuje użycie oddzielnych klonów (oddzielnych repozytoriów) przynajmniej dla długotrwałych gałęzi (jedna gałąź na przepływ pracy repozytorium), aka rozgałęzianie przez klonowanie.

Gałęzie w popychaniu

Mercurial domyślnie wypycha wszystkie głowice . Jeśli chcesz wcisnąć jedną gałąź (single head ), musisz określ wersję końcówki gałęzi, którą chcesz wypchnąć. Możesz określić końcówkę gałęzi według jej numeru wersji( lokalna do repozytorium), identyfikatora wersji, nazwy zakładki (lokalna do repozytorium, nie zostanie przeniesiona) lub osadzonej nazwy gałęzi (named branch).

O ile to rozumiem, jeśli wypchniesz szereg zmian, które zawierają commity oznaczone jako znajdujące się w jakiejś "nazwanej gałęzi" w języku Mercurial, będziesz miał tę "nazwaną gałąź" w repozytorium, do którego naciskasz. Oznacza to, że nazwy takich osadzonych gałęzi ("nazwane gałęzie") to globalne (w odniesieniu do klonów danego repozytorium / projektu).

Domyślnie (z zastrzeżeniem zmiennej konfiguracyjnej push.default) "git push" lub "git push remote>" Git wypycha pasujące gałęzie, tzn. tylko te lokalne gałęzie, które mają swoje odpowiedniki już obecne w zdalnym repozytorium, do którego wciskasz. Możesz użyć --all opcji git-push ("git push --all") aby wypchnąć wszystkie gałęzie , możesz można użyć pilota " git push > branch >" aby nacisnąć podaną pojedynczą gałąź, możesz użyć "git push remote> HEAD" aby nacisnąć bieżącą gałąź.

Wszystkie powyższe założenia zakładają, że Git nie jest skonfigurowany, które gałęzie mają być przesyłane przez zmienne konfiguracyjne remote.<remotename>.push.

Gałęzie w pobieraniu

Notatka: tutaj używam terminologii Gita, gdzie "fetch" oznacza pobieranie zmian ze zdalnego repozytorium bez integracji tych zmian z pracą lokalną. To właśnie robią "git fetch "i" hg pull".

Jeśli dobrze to Rozumiem, domyślnie Mercurial pobiera wszystkie głowice ze zdalnego repozytorium, ale możesz określić gałąź do pobrania poprzez "hg pull --rev <rev> <url>" lub "hg pull <url>#<rev>", aby uzyskać pojedynczą gałąź. Możesz określić używając identyfikatora rewizji, nazwy "named branch" (branch osadzony w changelogu) lub nazwy zakładki. Nazwa zakładki jednak (przynajmniej obecnie) nie daj się przenieść. Wszystkie zmiany "nazwane gałęzie", które otrzymujesz, należą do get transfered. "Hg pull" przechowuje końcówki gałęzi, które pobiera jako anonimowe, nienazwane głowy.

W Git domyślnie (dla zdalnego 'origin' utworzonego przez "git clone", oraz dla zdalnych utworzonych przez "git remote add") "git fetch" (or "git fetch <remote>") pobiera wszystkie gałęzie ze zdalnego repozytorium (z przestrzeni nazw refs/heads/) i przechowuje je w przestrzeni nazw refs/remotes/. Oznacza to np. gałąź o nazwie "master" (pełna nazwa: "refs/heads/master") w zdalnym "origin" zostanie zapisany (zapisany) jako "origin/master" oddział zdalnego śledzenia (pełna nazwa: "refs/remotes/origin/master").

Możesz pobrać pojedynczą gałąź W Git używając git fetch <remote> <branch> - Git przechowuje żądaną gałąź(Es) w FETCH_HEAD, co jest czymś podobnym do Mercurial unnamed heads.

To tylko przykłady domyślnych przypadków potężnego refspec składnia Gita: za pomocą refspecs możesz określić i / lub skonfigurować które gałęzie, które chce się pobrać i gdzie je przechowywać. Na przykład domyślny przypadek "fetch all branch" jest reprezentowany przez' + refs/heads/*:refs/remotes/origin/* 'wieloznaczny refspec, a "fetch single branch" jest skrótem od'refs/heads/:'. Refspecs są używane do mapowania nazw gałęzi (refs) w zdalnym repozytorium na lokalne nazwy refs. Ale nie musisz wiedzieć (dużo) o refspecs aby móc efektywnie pracować z Gitem (głównie dzięki " git remote" dowództwo).

^{osobista opinia: osobiście uważam, że" nazwane gałęzie " (z nazwami gałęzi osadzonymi w metadanych zestawów zmian) w Mercurial są błędnym projektem z globalną przestrzenią nazw, szczególnie dla rozproszonego systemu kontroli wersji . Weźmy na przykład przypadek, gdy zarówno Alice, jak i Bob mają w swoich repozytoriach" named branch " o nazwie 'for-joe', gałęzie, które nie mają ze sobą nic wspólnego. W repozytorium Joe jednak te dwie gałęzie zostaną źle potraktowane jako jedna gałąź. Więc w jakiś sposób wymyśliłeś konwencję chroniącą przed konfliktami nazw gałęzi. To nie jest problem z Git, gdzie w repozytorium Joe 'for-joe' gałąź od Alice będzie 'alice / for-joe', a od Bob 'bob / for-joe'. Zobacz także oddzielanie nazwy gałęzi od tożsamości gałęzi problem poruszony na Mercurial wiki.}

Mercurial ' s "bookmark branches" obecnie brak dystrybucji in-core mechanizm.

Różnice:
Ten obszar jest jedną z głównych różnic między Mercurial i Git, jak powiedzieli w swoich odpowiedziach james woodyatt[123]}i Steve Losh[123]}. Mercurial domyślnie używa anonimowych, lekkich linii kodowych, które w swojej terminologii nazywane są "głowami". Git używa lekkich nazwanych gałęzi, z mapowaniem injekcyjnym do mapowania nazw gałęzi w zdalnym repozytorium do nazw gałęzi zdalnego śledzenia. Git "zmusza" cię do nazwania oddziałów (cóż, z wyjątkiem jednej bezimiennej gałęzi, sytuacja zwana odłączoną głową), ale myślę, że działa to lepiej z ciężkimi przepływami pracy, takimi jak przepływ pracy w gałęzi tematycznej, co oznacza wiele gałęzi w paradygmacie pojedynczego repozytorium.

Zmiany nazewnictwa

W Git istnieje wiele sposobów nazywania zmian (opisanych np. na stronie Man git rev-parse):

• pełna nazwa obiektu SHA1 (40-bajtowy łańcuch szesnastkowy), lub podłańcuch takiego, który jest unikalny w repozytorium
W 2007 roku firma została założona przez firmę Microsoft, która od 2007 roku zajmuje się dystrybucją i dystrybucją sprzętu komputerowego.]}
• przyrostek ^ do parametru revision oznacza pierwszy rodzic commita, ^n oznacza n-ten rodzic commita scalającego. Przyrostek ~n do parametru revision oznacza n-tego przodka commita w prostej linii pierwszego rodzica. Przyrostki te mogą być łączone, tworząc specyfikację rewizji po ścieżce z odniesienie symboliczne, np. "pu~3^2~3'
• wyjście "Git describe", tzn. najbliższego tagu, opcjonalnie po którym następuje myślnik i liczba commitów, a następnie myślnik, 'g' i skrócona nazwa obiektu, na przykład'v1.6.5.1-75-g5bf8097'.

Istnieją również specyfiki rewizji obejmujące reflog, nie wymienione tutaj. W Git każdy obiekt, czy to commit, tag, tree czy blob ma swój identyfikator SHA-1; istnieje specjalna składnia, jak np. ' next: Documentation 'lub' next:README ' do odwołania do drzewa (katalogu) lub blob (zawartości pliku) przy podanej rewizji.

Mercurial ma również wiele sposobów nazwania zestawów zmian (opisanych np. w Hg manpage):

• zwykła liczba całkowita jest traktowana jako liczba rewizji. Należy pamiętać, że numery wersji są lokalne dla danego repozytorium ; w innym repozytorium mogą być różne.
• ujemne liczby całkowite są traktowane jako sekwencyjne przesunięcia od końcówki, z -1 oznaczającym końcówkę, -2 oznaczającym rewizja przed końcówką i tak dalej. Są również lokalne do repozytorium.
• unikalny identyfikator rewizji (40-cyfrowy łańcuch szesnastkowy) lub jego unikalny prefiks.
• nazwa znacznika (symboliczna nazwa powiązana z daną rewizją), lub nazwa zakładki (z rozszerzeniem: symboliczna nazwa powiązana z daną rewizją, lokalna do repozytorium), lub " named branch "(Etykieta zmian; zmiana podana przez "named branch" jest wskazówką (bezdzietnym zatwierdzeniem) wszystkich zmian z podaną etykietą zmian, z największa liczba zmian, jeśli istnieje więcej niż jedna taka końcówka)
• zastrzeżona nazwa " tip " jest specjalnym znacznikiem, który zawsze identyfikuje najnowszą wersję.
• zastrzeżona nazwa "null" oznacza zmianę null.
• nazwa zastrzeżona"."wskazuje rodzica katalogu roboczego.

Różnice
Jak widać porównując powyższe listy Mercurial oferuje numery wersji, lokalne do repozytorium, podczas gdy Git nie. z drugiej strony Mercurial oferuje względne offsety tylko z ' tip '(bieżąca gałąź), które są lokalne dla repozytorium (przynajmniej bez ParentrevspecExtension ), podczas gdy Git pozwala określić dowolny commit następujący po każdej końcówce.

Ostatnia wersja nosi nazwę HEAD w Git, a " tip " w Mercurial; w Git nie ma wersji null. Zarówno Mercurial, jak i Git mogą mieć wiele commitów root (może mieć więcej niż jeden commit bez parentless; zwykle jest to wynik połączenia wcześniej oddzielnych projektów).

Zobacz też również: wiele różnych rodzajów poprawek artykuł na blogu Eliasza (newren ' s).

^{osobista opinia: myślę, że numery wersji są przereklamowane (przynajmniej dla rozproszonego rozwoju i/lub nieliniowej / rozgałęzionej historii). Po pierwsze, w przypadku rozproszonego systemu kontroli wersji muszą one być albo lokalne dla repozytorium, albo wymagać traktowania jakiegoś repozytorium w specjalny sposób jako centralnego organu numerującego. Po drugie, większe projekty, z dłuższa historia, może mieć liczbę zmian w zakresie cyfr 5, więc są one oferują tylko niewielką przewagę nad skróconymi do identyfikatorów 6-7 znaków rewizji, i implikują ścisłe porządkowanie, podczas gdy zmiany są tylko częściowo uporządkowane (mam na myśli tutaj, że zmiany n I n+1 nie muszą być rodzicem i dzieckiem).}

Przedziały rewizji

W Git przedziały rewizji są topologiczne . Powszechnie widziana A..B składnia, która dla historii liniowej oznacza zakres zmian zaczynający się od (ale wykluczając A), a kończący się na B (tzn. zakres jest otwarty od dołu), jest skrótem ("cukrem składniowym") dla ^A B, co dla poleceń przechodzenia historii oznacza wszystkie commity osiągalne z B, wyłączając te osiągalne z A. Oznacza to, że zachowanie zakresu A..B jest całkowicie przewidywalne (i całkiem użyteczne) nawet jeśli A nie jest przodkiem B: A..B oznacza zakres zmian od wspólnego przodka a i B (merge base) do rewizji B.

W Mercurial revision zakresy są na podstawie zakresu numerów rewizji . Zakres jest określony za pomocą składni A:B i w przeciwieństwie do Gita range działa jako zamknięty interwał. Również range B: A jest range A: B w odwrotnej kolejności, co nie ma miejsca w Git (patrz niżej notatka na temat składni A...B). Ale taka prostota przychodzi z ceną: zakres A: B ma sens tylko wtedy, gdy A jest przodkiem B lub odwrotnie, tzn. z historią liniową; w przeciwnym razie (chyba tak) zakres jest nieprzewidywalny, a wynik jest lokalny do repozytorium (ponieważ numery wersji są lokalne dla repozytorium).

Jest to ustalone za pomocą Mercurial 1.6, który ma nowy topologiczny zakres rewizji , gdzie " A..B' (lub 'A::B') jest rozumiane jako zbiór zestawów zmian, które są zarówno potomkami X, jak i przodkami Y. jest to, jak sądzę, odpowiednik ' --ancestry-path A..B ' In Git.

Git posiada również notację A...B dla symetrycznej różnicy zmian; oznacza ona A B --not $(git merge-base A B), co oznacza wszystkie commity osiągalne z A lub B, ale wyłączając wszystkie commity osiągalne od obu z nich (osiągalne od wspólnych przodków).

Zmienia nazwy

Git jest unikalny wśród systemów kontroli wersji, ponieważ używa detekcji rename detection do obsługi zmian nazw plików. Oznacza to, że fakt, że nazwa pliku została zmieniona, jest wykrywany w czasie, gdy jest potrzebny: podczas scalania lub podczas wyświetlania różnic (jeśli jest wymagane / skonfigurowane). Ma to tę zaletę, że algorytm wykrywania zmiany nazwy może zostać ulepszony i nie jest zamrożony w momencie zatwierdzania.

Zarówno Git jak i Mercurial wymagają użycia --follow opcja śledzenia zmian nazw podczas wyświetlania historii pojedynczego pliku. Oba mogą śledzić zmiany nazw podczas wyświetlania liniowej historii pliku w git blame / hg annotate.

W Git polecenie git blame jest w stanie śledzić ruch kodu, również przenosząc (lub kopiując) kod z jednego pliku do drugiego, nawet jeśli ruch kodu nie jest częścią całej zmiany nazwy pliku. Z tego co wiem Ta funkcja jest unikalna dla Gita (w momencie pisania, październik 2009).

Sieć protokoły

Zarówno Mercurial, jak i Git mają wsparcie dla pobierania i przesyłania do repozytoriów na tym samym systemie plików, gdzie adres URL repozytorium jest tylko ścieżką systemu plików do repozytorium. Oba mają również wsparcie dla pobierania z bundle files .

Obsługa Mercurial pobieranie i przesyłanie przez protokoły SSH i HTTP. Dla SSH potrzebne jest dostępne konto shell na docelowej maszynie i kopia Hg zainstalowana / dostępna. Dla dostępu HTTP hg-serve lub Mercurial Wymagane jest uruchomienie skryptu CGI, a Mercurial musi być zainstalowany na maszynie serwerowej.

• " inteligentne " protokoły, które zawierają dostęp przez SSH i poprzez Niestandardowy protokół git:// (przez git-daemon), wymagają zainstalowania git na serwerze. Wymiana w tych protokołach polega na negocjowaniu przez Klienta i serwer, jakie obiekty mają ze sobą wspólne, a następnie generowaniu i wysyłaniu pliku packfile. Nowoczesny Git zawiera wsparcie dla "smart" protokołu HTTP.
• "głupie" protokoły , które obejmują HTTP i FTP (tylko do pobierania) oraz HTTPS (do przesyłania przez WebDAV), nie wymagają zainstalowania git na serwerze, ale wymagają, aby repozytorium zawierało dodatkowe informacje generowane przez git update-server-info (zwykle uruchamiane z Hooka). Exchange polega na tym, że Klient przechodzi przez łańcuch zatwierdzeń i pobiera luźne obiekty i pliki packfiles w razie potrzeby. Minusem jest to, że pobiera więcej niż ściśle wymagane (np. w przypadku, gdy jest tylko jeden plik packfile, zostanie on pobrany w całości nawet przy pobieraniu tylko kilku wersji), i że może wymagać wielu połączeń, aby zakończyć.

Git jest zaimplementowany w C, Perl i skrypty powłoki . Git dostarcza wiele niskopoziomowych poleceń (plumbing) odpowiednich do użycia w skryptach. Standardowym sposobem wprowadzenia nowej funkcjonalności jest zapisanie jej jako skryptu Perla lub powłoki, a gdy interfejs użytkownika się ustabilizuje, przepisanie jej w C pod kątem wydajności, przenośności, a w przypadku powłoki skrypt unikający przypadków narożnych (procedura ta nazywa się builtinification ).

Git opiera się i jest zbudowany w oparciu o formaty [repozytorium] i protokoły [sieciowe]. Zamiast powiązań językowych istnieją (częściowe lub całkowite) reimplementacje Gita w innych językach (niektóre z nich są częściowo reimplementacjami i częściowo opakowaniami wokół komend Gita): JGit (Java, używana przez EGit, Eclipse Git Plugin), Grit (Ruby), Dulwich (Python), git# (C#).

TL; DR