Dlaczego Git zyskał tyle szumu? … Podczas gdy inni nie? [Zamknięte]

W ostatnich latach wzrosła popularność wokół Gita. Wszyscy wiedzą o Git, nikt nie wie o alternatywach.

Inne, takie jak Mercurial, wydają się być niezauważone. Oba zostały wydane w 2005 roku i zapewniają podobne funkcje. Co więcej, Mercurial jest ogólnie uważany za łatwiejszy w użyciu, bardziej intuicyjny i przez długi czas miał lepsze interfejsy użytkownika. Dlatego można założyć, że byłaby to popularna alternatywa, szczególnie dla tych, którzy dopiero zaczynają rozproszoną kontrolę wersji. Jednak dla większości ludzi wydaje się to nieznane, w przeciwieństwie do Gita, któremu udało się całkiem nieźle.

Celem tego postu jest próba lepszego zrozumienia tego zjawiska.

Jak to się dzieje, że Git dostaje część ciasta? Czy w jakiś sposób korzystali z lepszego marketingu? Czy to dlatego, że jego społeczność jest bardziej… hmm… „pełna”? Czy to z powodu nazwy „Linus”? Czy to z powodu jego naukowego wizerunku?

Jakie jest Twoje zdanie?

Uważam, że usługi takie jak GitHub lub Gitorious to duży czynnik. Ważne jest, aby ludzie mogli gdzieś hostować swoje rzeczy, a zwłaszcza GitHub to świetna usługa.

W przypadku rtęci nie było takiej usługi, kiedy DVCS stało się popularne (przynajmniej żadnej, o której nie wiedziałem). Masz teraz Bitbucket i prawdopodobnie inne, ale GitHub istnieje już od dłuższego czasu, jest dobrze znany i staje się coraz lepszy.

Widzę wiele odpowiedzi na to pytanie, które opierają się na odczuciach autora, gdy usłyszałem o jednym lub drugim SCM. Inni mówią, że to wszystko było zwykłym szczęściem. Wierzę, że szczęście można prześledzić w historii.

Opowiem o historii.

Git i Mercurial zostały utworzone jednocześnie, aby rozwiązać ten sam problem. W tamtych czasach jądro Linuksa było zmuszone przestać używać BitKeeper , zastrzeżonego, rozproszonego SCM, z którego korzystał przez 3 lata. Powodem tego był fakt, że Larry McVoy, dyrektor generalny BitMover, firmy stojącej za BitKeeper, przestał rozdawać swoje oprogramowanie za darmo programistom Linuksa, ponieważ ktoś ze społeczności Linuksa poddał go inżynierii wstecznej.

Linus Torvalds, niezadowolony z tego, co już istniało, zaczął później pracować nad nowym SCM, który wkrótce nazwał Git. Wkrótce potem Matt Mackall rozpoczął projekt Mercurial z podobnych powodów.

Po pewnym czasie opracowywania tych projektów osobno Matt Mackall zaprezentował zaawansowaną wersję swojego SCM i porównał go w pewien sposób, porównując go do Gita (który miał zaledwie kilka tygodni). Linus rozważał użycie go zamiast Git do rozwoju jądra, ale porzucił ten pomysł, gdy zdał sobie sprawę, że Mercurial używa zestawów zmian do rejestrowania modyfikacji wersji . Obawiał się, że jest to zbyt blisko sposobu działania BitKeepera i na pewno nie chciał niczego, co mogłoby zmusić kogoś do powiedzenia: „Zbudowali klon BitKeepera”.

Git został więc użyty do rozwoju jądra zamiast Mercurial, ale oba były technicznie istotne. Rezultat końcowy jest taki, że Git zaczął od użycia go tam, gdzie został zaprojektowany, podczas gdy Mercurial nie był tak szybki, aby znaleźć pierwsze duże zastosowanie FOSS. Ponieważ został wyposażony w bardzo dobry projekt, a dzięki wytrwałości Matta Mackalla, ostatecznie stał się sławny i przywykł do dużych, rzeczywistych projektów.

Dziś oboje są sławni. Który z nich jest najbardziej znany, nie można powiedzieć. Google Code dopiero niedawno zintegrował Git, choć od dawna miał Mercurial. Korzysta z nich wiele naprawdę dużych i znanych projektów.

Myślę, że mam na myśli to, że kiedy sam powód, dla którego zacząłeś projekt, zanika, trudniej jest zdobyć popularność, ale nadal jest to wykonalne.

Bazaar to kolejny SCM, który jest bardzo znany w świecie GNU, ale nie tak bardzo poza nim, ponieważ został zbudowany w celu zadowolenia społeczności GNU. Oprogramowanie często trafia tam, gdzie chcą iść ich twórcy, i nic więcej.

Z drugiej strony rozproszone SCM są wyraźnymi zwycięzcami. Nie widzę tam wielu szeroko rozpowszechnionych SCM.

Linus Torvalds

Linus jest wielkim zwolennikiem Git i od lat mocno awansuje do głównej grupy linuxowej i od tego czasu rośnie. Śmiem twierdzić, że jest to całkowicie spowodowane wpływem Linusa na społeczność * nix.

Osobiście nadal używam Subversion, ale to raczej preferencja niż użyteczność.

Zwykłym problemem w systemie kontroli wersji jest łączenie gałęzi .

Musisz go wypróbować, gdy to nie działa, aby zrozumieć, jak bolesne może być i jak ważne jest mieć pracę, aby swobodnie pracować z gałęziami.

Dowiedziawszy się, że Linus Torvalds napisał git, aby zrobić to dobrze, i rzekomo w jednej sytuacji użył git do połączenia dwunastu gałęzi jednocześnie, jest to bardzo przekonujący argument za tym, aby git był interesujący.

Byłem w sytuacji około rok temu, kiedy musiałem wybierać między hg a git, a powyższe połączenie było jednym ważnym czynnikiem przy wyborze git. Po drugie, organizacja Eclipse przeszła na git, więc oczekiwano, że narzędzia Eclipse będą dobre dla projektów Java. Tak stało się wraz z wydaniem Eclipse 3.7. Byliśmy może 6-9 miesięcy wcześniej.

Do różnych potrzeb hg może być równie przydatne. Firma Sun wybrała go do VCS na podstawie bardzo starannego dochodzenia. Możesz znaleźć białe księgi i zobaczyć, jakie były ich uzasadnienia.

EDYCJA: Uwaga, nie mówię, że jest coś, czego Mercurial nie może zrobić, tylko to, że w Javie z Eclipse - co jest naszym głównym celem - siły rynkowe są obecnie najsilniejsze dla git, nawet pod Windows, i musimy stać na ramieniu innych, nie ich stóp.

Zamiast powiedzieć, dlaczego git lub mercurial jest lepszy i powiedzieć, że jest to jedyny powód, dla którego jest popularny, skupię się na społeczności.

Jak podkreśliłem wcześniej , społeczność Git jest bardzo głośna i arogancka. Większość będzie energicznie bronić swojego cennego programu. Większość wojen Git kontra Mercurial, które widziałem, rozpoczęły się od ludzi, którzy zastanawiali się, dlaczego wszyscy na Ziemi nie używają świętego dupka. Strony takie jak whygitisbetterthanx.com pokazują nawet tę arogancję we wstępie, który jest napisany, by prowokować innych.

Nie twierdzę, że wszyscy są tacy, ale przez większość czasu, gdy spotkałem ludzi z git, pro-git i blogi z pro-git, czułem, że git jest wrzucany mi do gardła zamiast oferowany jako realny DVCS system.

Natomiast inne społeczności DVCS nie są tak głośne. Nie wiedziałem, że Mercurial istnieje, dopóki nie zobaczyłem „Jaki jest najlepszy DVCS?” pytanie dotyczące SO. Podczas gdy git pojawia się wszędzie, inne DVCS potrzebują czasu na znalezienie.

Nie sądzę, że Mercurial jest szczególnie niski. Kiln jest zbudowany na Hg i od pewnego czasu istnieje dobre wsparcie w IDE, takich jak Eclipse i Netbeans.

Większość programistów, z którymi rozmawiam, wydaje się preferować Hg ze względu na lepszą obsługę Windows. Gdybyśmy byli programistami Linuksa, mogłaby to być inna historia.

Brakuje również „Bazaar”, który jest prawdziwym „zapomnianym DVCS”.

Z pewnością zgadzam się z tym, że Linus jest bardzo charyzmatycznym facetem i kujonem alfa prawie bez równych sobie, więc wiele osób skłania się do Gita z tego powodu. Ponadto „Mit stworzenia Gita” jest bardzo przekonujący, ponieważ Linus pracuje 6 dni, aby stworzyć Gita i spoczywa na siódmym - lub coś w tym rodzaju. Gdy produkt ma niezapomnianą historię, łatwiej jest uzyskać przyczepność.

To skromna opinia, ale git może uzyskać cały ten szum z powodu dwóch parametrów:

1. Jest bardzo wydajny
2. Jest przyjemny w użyciu (w pewien specyficzny sposób dla informatyków)

Dodatkowo, git ma aplikację typu killer, taką jak github, a niektóre bardzo popularne projekty postanowiły jej użyć, co zapewniło jej dużą widoczność.

Działają tutaj trzy czynniki: „beta geek media”, „czas jest odpowiedni” i „podążać za liderem”

Beta Geek Media

Istnieje wiele kanałów, które omawiają „działania naukowców”. Z pewnością obejmowałyby pojawienie się nowego systemu kontroli wersji, ale obejmują więcej git. Dlaczego? Ponieważ Linus Torvalds napisał go początkowo, spierał się o to publicznie i wykorzystał go jako rozwiązanie swojego dobrze nagłośnionego problemu z bitkeeperem. Skutecznie, za każdym razem, gdy na Lkml wybuchnie wojna płomieni, media maniaków wersji beta napiszą o tym artykuł. Dyskusja na temat Git rozpoczęła się na lkml, więc zyskała większy zasięg niż inne alternatywy. A maniacy wersji beta, którzy czytają slashdota, jakby to było Odmiana, zjadli go. Ostatecznym rezultatem tego jest to, że git ma dziesięć razy więcej artykułów niż rtęci.

Czas jest właściwy

Duże projekty open source z dużą liczbą współpracowników mają problemy ze scentralizowaną kontrolą źródła. W miarę rozwoju otwartego oprogramowania i coraz większego prawdopodobieństwa, że ​​projekty będą miały wielu współautorów, problem się pogarsza. Linux jest prawdopodobnie najbardziej znanym projektem cierpiącym z tego powodu, ale istnieje wiele innych. Ponieważ wiele projektów osiągnęło ten punkt, potrzebny był pewien rodzaj zaawansowanego VCS. Git, Mercurial i Bazaar byli tutaj dużymi zwycięzcami. Arch i Monotone byli tylko trochę za wcześnie i przegapili falę szumu.

Podążaj za liderem

Duże projekty mają obserwujących, którzy regularnie sprawdzają i budują kod, nawet jeśli nie wnoszą wkładu. Obserwujący zapoznają się z narzędziami potrzebnymi do pobrania obserwowanego projektu, aby te narzędzia były w większym stopniu wykorzystywane. Rzućmy okiem na projekty „dużego losowania” dla wielkich trzech DVCS:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Bazar : Ubuntu, Emacs

Git ma więcej projektów wykorzystujących go, więc więcej osób zna git, jest więcej samouczków git.

To głównie po prostu samowzmacniający się szum. Git jest najbardziej popularny, więc zyskuje najwięcej rozgłosu, co powoduje, że staje się bardziej popularny.

Git, Hg i Bzr są doskonale dobrymi systemami DVCS, ale przerażająca liczba ludzi utożsamia DVCS z Git i uważa, że ​​wszystkie piękne funkcje DVCS są unikalne dla Git. Dlatego używają Gita i polecają Gita, mówiąc: „Git jest lepszy, ponieważ może wykonywać scalenia ośmiornic” (podobnie jak Bazar), lub „Git jest lepszy, ponieważ jest dystrybuowany” (podobnie jak każdy DVCS, stąd nazwa ) lub „Git jest lepszy, ponieważ ułatwia rozgałęzianie i scalanie” (ponownie, dotyczy to każdego DVCS).

Niestety, ponieważ uważam, że alternatywy mają również wiele do zaoferowania i wolałbym, aby ludzie wybrali Git ze względu na jego wyjątkowe zalety, niż po prostu dlatego, że myślą, że DVCS == Git.

Kiedy ktoś odkrywa, jak sprytne są DVCS, wskazując na jeden konkretny DVCS, często nie idzie i nie mówi innym „hej, DVCS są świetne, powinieneś ich używać”, a raczej „DVCS, które ja dowiedziałeś się o DVCS od jest świetny, powinieneś go używać ".

Github. Github jest pionierem w kodowaniu społecznym. Przekształcił kontrolę wersji w platformę społecznościową, która przyciągnęła wiele uwagi i oczywiście obsługuje Git. Media społecznościowe = większa adopcja. Bitbucket zyskuje na popularności, zyskując wiele nowych funkcji, dzięki czemu jest prawdopodobnie rywalem :)

Cóż, tak naprawdę myślę, że szum jest o wszystkich połączeniach DSVC.

Ale zwolennicy gita są po prostu bardziej głośni, często bardziej agresywni w swoich komentarzach, aby być szczerym i lubią o tym mówić wszędzie.

Podejrzewam, że Mercurial jest szeroko stosowany, na pewno tak często jak git, może więcej (Microsoft i inne duże firmy używają go teraz), ale ludzie używający Mercurial najczęściej chcieli po prostu DSVC, który mogliby szybko uchwycić, a nie coś, na czym mogliby oprzeć religię. Są więc mniej głośni i bardziej reaktywni w dyskusjach niż proaktywni, jak niektórzy użytkownicy git.

Na Bazaar nie mówi się zbyt wiele, ponieważ korzysta z niego tylko kilka dużych znanych projektów i nie są znane żadne inne duże firmy poza firmą Canonical. Porównaj na przykład z Google (git, mercurial, svn) i dużymi projektami typu open source, a zobaczysz, dlaczego tak naprawdę nie mówi się o tym. Fossil jest kolejnym, który jest interesujący dla niszy deweloperów, więc myślę, że to normalne i w porządku, że słyszą je tylko ci, którzy przeszukują oferowane przez nich funkcje (takie jak osadzone wiki, śledzenie problemów i forum).

Biorąc to pod uwagę, myślę, że powoli schodzimy z hype cyklu i wielu programistów, którzy korzystali z kilku różnych rozwiązań, może zacząć widzieć, które z nich odpowiadają ich potrzebom.

Ponadto Google Code Hosting i SourceForge pozwalają teraz zarówno na git, jak i mercurial, więc staje się bardziej wyborem specyficznym dla projektu niż wcześniej, gdy wybrałeś git ze względu na funkcje GitHub.

Nie ma prawdziwej wojny, tylko interesująca różnorodność narzędzi.

Wiem, że jest już wiele odpowiedzi na to pytanie, ale czułem, że mogę dodać nieco więcej perspektywy.

Korzystałem z Bazaar prawie od kiedy został stworzony do różnych rzeczy. Największą rzeczą, z której korzystałem, był projekt AllTray, dla którego jestem (obecnie) jedynym programistą i opiekunem. Bazar jest fajny. Po prostu działa, nie przeszkadza mi i prawie nigdy nie muszę patrzeć na stronę --help lub manual. To powiedziawszy, jest kilka wad:

1. Nie ma wielu funkcji, które prawdopodobnie powinny być częścią podstawowego VCS. Rzeczy takie jak możliwość przeprowadzenia podziału historii, uruchamiania długich wyników przez pager lub posiadania „kolokowanych” gałęzi (np. Repozytoriów w stylu git) są dostarczane jako wtyczki.
2. Wiele wtyczek nie jest tak stabilnych. Na przykład funkcjonalność kolokowanych gałęzi wydaje się nie działać dobrze po stronie serwera (przynajmniej nigdy nie udało mi się tego uruchomić, często mylnie mówiąc, że gałąź przy danej ścieżce nie istnieje, gdy jest tuż przed tobą i możesz zobaczyć krwawą rzecz).
3. Nie ma operacji „klonowania”, ciągniesz gałęzie pojedynczo. Musisz wykonać dodatkową pracę, jeśli chcesz mieć repozytorium, aby móc skutecznie wyciągać nowe gałęzie.
4. W przypadku niektórych projektów jest to boleśnie powolne. Spróbuj „bzr branch lp: mysql”.
5. Brakuje mocnego wsparcia dla haczyków; możesz pisać wtyczki bzr, które zapewniają przechwytywanie, ale nie ma standardowego sposobu na tworzenie dowolnych skryptów przechwytujących po stronie serwera.

Niedawno przeszedłem na git do programowania AllTray i bardzo szybko rozważam migrację wszystkich moich projektów do git. Na zapoznanie się z linami jest trochę więcej czasu z góry, ale wydaje się, że warto. Niektóre rzeczy, które zauważyłem:

1. git clone jest stosunkowo szybką operacją i zapewnia informacje o wszystkich gałęziach istniejących w sklonowanym repozytorium.
2. Dodawanie dodatkowych zdalnych repozytoriów jest bezbolesne, więc możesz śledzić wiele różnych repozytoriów, które mają wiele oddziałów, jeśli chcesz.
3. Książka Pro Git jest dostępna online i w wielu formatach, w tym na czytniki eBooków - i nie jest to trudna lektura.
4. Wydaje się, że git jest znacznie łatwiejszy do rozszerzenia niż Bazaar i nie musisz do tego używać żadnego konkretnego interfejsu API. (Uwaga: jest to zarówno plus, jak i minus).
5. git ma wbudowaną opcję bisekcji i nie mogę wystarczająco podkreślić użyteczności tej funkcji.
6. GitHub jest raczej fajny.
7. gitosisSystem jest dość miłe. Nie jestem nawet pewien, jak można by to zaimplementować inaczej niż jako wtyczkę w Bazaar i nie wyobrażam sobie, że byłoby to tak wydajne.

Krótko mówiąc: Używam bzr od bardzo dawna, ale git szybko udowadnia mi swoją niesamowitość.

Korzystając z git, zawsze robisz programowanie w tym samym katalogu lokalnym i po prostu git checkout branchnameprzełączasz się między gałęziami (używam gałęzi funkcji „lekkich” przez cały czas, więc jest to dla mnie bardzo ważna funkcja).

Patrząc na dokumentację i samouczki Mercurial, wydaje się, że preferowanym sposobem radzenia sobie z różnymi gałęziami rozwoju jest tworzenie nowych repozytoriów poprzez klonowanie. Ten samouczek jest przykładem.

Wierzę, że możesz zrobić to samo w Mercurial jak w git, ale z jakiegoś powodu dokumentacja Mercurial (którą przeczytałem) prawie zawsze pokazuje rozgałęzienie poprzez utworzenie klonu repozytorium.

(Używam git codziennie. Mam niewielkie doświadczenie z merkurialem, bawiłem się nim i wykonałem kilka samouczków)

Nie wiem, ile takich rantów widziałem w ciągu ostatnich kilku tygodni, ale wydaje się, że wszyscy uważają to za fakt, że Mercurial i / lub Bazaar są obiektywnie lepsze niż Git. Użyteczność wydaje się być powszechnym tematem. Tak, nauka Gita była zaskakująco trudna po użyciu CVS i Subversion, ale w tym momencie nie chciałbym go wymieniać na żaden inny VCS, chyba że stanowiłoby to kolejną zmianę paradygmatu . Wskazanie na tabelę funkcji niewiele mi powie o tym, jak elastyczna, rozszerzalna, bezpieczna lub bezproblemowa . Na przykład domyślnie git-diff używa kolorów i pagera. Jasne, że mogę uzyskać to samo z diff ... | colordiff | less -Rczymś, ale powinno być oczywiste, dlaczego jedno jest lepsze od drugiego.

Szczerze mówiąc, myślę, że zwolennicy git vs. merkurialni są nieliczni i daleko od siebie w porównaniu do git vs. Jednak przyczyny są łatwe do podsumowania:

Git to kontrola wersji dla programistów. Mercurial to kontrola wersji dla przedsiębiorstw. Scentralizowana była odpowiednią pierwszą próbą wymyślenia kontroli wersji, zwłaszcza biorąc pod uwagę, że została ona zaprojektowana przed rewolucją komputerów osobistych.

Mam na myśli kontrolę wersji dla programistów, że programiści ogólnie wolą elastyczność niż łatwość uczenia się. W końcu jesteśmy gotowi spędzić lata na nauce języków ezoterycznych, aby mieć elastyczność, dzięki której komputery mogą robić to, czego nie potrafią wyszkoleni. Git daje programistom elastyczność w korzystaniu z nich w dowolny sposób, kosztem dłuższego uczenia się, jak bezpiecznie korzystać z tej elastyczności. Pozwala na wprowadzenie ograniczeń w celu egzekwowania zasad, ale nie wychodzi tak prosto z pudełka. Uwaga Powiedziałem, że łatwość uczenia się, a nie łatwość użytkowania . Gdy się go nauczysz, git jest równie łatwy w użyciu, jak każdy inny VCS, i często łatwiejszy ze względu na zwiększoną szybkość i funkcje.

Niektórzy programiści uczą się wystarczająco, aby robić to, co chcą, a następnie nie chcą się uczyć nowych sposobów. Przedsiębiorstwa zatrudniają i zatrudniają wiele z tych osób, dlatego chcą, aby wszelkie zmiany w używanych przez nich narzędziach były w pewnym stopniu znane. Przedsiębiorstwa chcą również, aby ich programiści mieli wystarczającą elastyczność, aby wykonywać swoje zadania, ale nie tak bardzo, aby utrudniać szkolenie lub początkową migrację. Właśnie tam wpasowuje się merkurial. Ma większość mocy git, ale nieco łatwiejszą ścieżkę migracji.

Nie sądzę, aby można było powiedzieć, że git jest popularny tylko z powodu szumu lub poparcia Linusa. Prawdopodobnie stanowi to przyczynę wielu osób próbujących go, ale trzymają się go i promują, ponieważ działa dla nich dobrze, czysto i prosto.

Programowanie w NetBSD wykorzystuje CVS i to wszystko, co ważne.

Ma fajniejsze, bardziej zwięzłe imię, które dobrze nadaje się do gry słów.

Niedawno szukałem systemu kontroli wersji dla osobistych projektów, więc właśnie wypróbowałem kilka z nich. Jestem praktycznie analfabetą w linii poleceń i słyszałem, że chociaż GUI są dostępne, Git naprawdę był przeznaczony do używania przez linię poleceń, co nieco mnie zawahało. Szczerze mówiąc, było to absurdalnie łatwe do odebrania i bardzo mi się to podoba. Dokumentacja jest ogromnym czynnikiem przy wdrażaniu nowej technologii, a Git ma mnóstwo śmiesznie prostej dokumentacji, która jest przejrzysta i dostępna. Inne alternatywy, takie jak SVN i Bazaar, były świetne, po prostu nie sprawiły, że było to tak łatwe jak Git. Github jest również ważnym czynnikiem, ponieważ w tej chwili stał się tak centralny dla ruchu open source. Posiadanie (ironicznie) scentralizowanej lokalizacji do wymiany kodu i projektów jest sama w sobie przełomem.

Tylko moje 2 ¢ - wybrałem git zamiast alternatyw, ponieważ jest napisany w C zamiast w języku radtool lub zbyt akademickim języku wysokiego poziomu. Zaletą jest to, że jest szybki i wydajny oraz że właściwie mogę RTFS, jeśli napotkam błędy lub zachowania, których nie potrafię wyjaśnić. Umożliwia także korzystanie z niewielkich środowisk deweloperskich, które nie zawierają gigantycznych interpreterów / środowisk wykonawczych, co oznacza, że ​​mogę bezpośrednio pobierać z repozytorium git i kompilować na takich systemach zamiast pobierać najnowsze źródła gdzie indziej i rsync.

Być może zechcesz przeczytać, dlaczego projekt pulpitu GNOME wybrał git zamiast hg i bzr, kiedy zdecydował się na przejście z svn kilka lat temu. Po drodze odbyło się wiele gorących dyskusji religijnych, ale ta strona Wiki GNOME ładnie podsumowuje zalety i wady, odnoszące się do tej konkretnej społeczności.

Nie wspominając już, że Apple zaangażowało się teraz w przekazywanie go społeczności docelowej c, jeśli niedawno utworzyłeś nową aplikację w Xcode 4, zauważysz, że automatycznie pyta cię, czy chcesz zrobić repozytorium Git.

Uznany Xcode 4 istnieje już od kilku miesięcy i nie ma wpływu na poprzedni sukces Gitsa, ale wszyscy wiemy, jak popularny Apple może robić rzeczy w krótkim czasie.

Obecnie przechodzę z hg (kiln) na git (github). Używam pieca od około roku. Dla mnie hg nie ma wad. Mogę zrobić wszystko, co muszę. To wspaniale.

Dlaczego teraz używam?

Są teraz tylko trzy powody.

1. gitHub oferuje świetne opcje
2. gitHub oferuje świetne funkcje społecznościowe
3. Podczas prezentacji i warsztatów dla programistów zawsze publikowałem swoje próbki na hg i git. Na git mam około 10 razy więcej odwiedzających niż na hg !!

Myślę, że trzeci jest najważniejszy.

Thorsten

Myślę, że szczęście, do tej pory prawie niemożliwe jest udowodnienie, dlaczego coś działało, a inne nie. Linus może zbudować coś spektakularnego i nie odniesie sukcesu.