Monthly Archive for March, 2008
Обосновывая свою точку зрения, в первую очередь, надо полагаться на состоятельность своих аргументов, а не на неточности в трактовках оппонента. Я так полагаю.
Миша Клишин рассказывает о Git’е, Mercurial’е (и Darcs’е) и FUD‘е. В двух словах: он рассказывает о том, как фенбои Mercurial’а его нервируют, как они критикуют Git за его сложность и некоторую недружелюбность к Windows (должен заметить, оправдано). И рассказывает, что Hg очень медлителен и никогда не доберется по скорости до Git’а (который даже быстрее файловой системы: “Git is faster than your file system”). Он приводит пример: конвертацию проекта в 800 Мб из Darcs в Mercurial, что заняла на его MBP 7 часов.
Интересно было бы посмотреть сколько заняла бы конвертация из Darcs в Git. Так, для сравнения. Потому, что данный пример всего-лишь говорит о скорости работы Hg, но никак не о том, что он намного медленнее Git’а. Да и выбранная задача очень актуальна. Например, я по несколько раз на день конвертирую большие репозитории.
Правда, он говорит пару слов о том, что стоит выбирать инструмент, который удовлетворяет твои нужды. Например, мои нужды удовлетворяет Bazaar. И делает он это гораздо лучше, чем Git. Наверное, потому, что я не ворочаю репозитории по гигу размером и мне не жалко двадцать три сотых секунды для дифа.
В последнее время поднимается все больший ажиотах вокруг DVCS‘ов. Многие (по крайней мере в рельсово-рубевой среде) склоняются к Git‘у. Ну, вот я и решил попробовать.
Скажу честно, я о нем слышал давно уже. Он используется для разработки линуксового ядра и xmms2. В отличии от своих ближайших соперников - Mercurial‘а и Bazaar‘а он написан на C, а не на python и потому очень быстрый. Но, наверное, по той же причине Mercurial и Bazaar имеют гораздо более дружелюбній интерфейс. Bazaar, например, даже обзавелся графическической оболочкой, которая позволяет делать все необходимое.
Но не о них речь, а о Git’е. Я уже говорил, что он не очень дружлюбен. Вот несколько примеров. Сразу говорю - я пришел с Subversion’а и никапли не стараюсь быть объективным, а даже наоборот.
Поскольку Git очень хочет быть DCVS, то неотъемлемой частью работы есть бранчевание и мержи. Вот о мержах и поговорим. А вернее о конфликтах, как неотъемлемой их части.
При пуле конфликты показываются так:
Auto-merged app/models/event.rb CONFLICT (content): Merge conflict in app/models/event.rbА вот в статусе нифига не понятно:
unmerged: app/models/event.rb modified: app/models/event.rbЧто самое плохое, автоматически не может смержить одинаковый код. Видимо, это связано с тем, что он не может понять кому в таком случае приписывать это изменение. Это связанно с тем, что Git хранит полную историю изменений при мержах, в отличии от того же Subvrsion’а.
< <<<<<< HEAD:config/initializers/google-geocoder.rb Geocode.geocoder = Graticule.service(:google).new GOOGLE_MAPS_API_KEY ======= Geocode.geocoder = Graticule.service(:google).new GOOGLE_MAPS_API_KEY >>>>>>> 14edde15cb190ebef2ef73e7ecf458c5b47853fd:config/initializers/google-geocoder.rbЕще у него страшные проблемы с интуитивностью интерфеса.
Вот как зарезолвить конфликты? У SVN’а есть resolve. У Bazaar’а есть resolve. А у Git’а - update-index. Это рекомендовали на kerneltrap’е.
Edit so the files have sensible content
then use
git update-index
to tell git that that particular conflict has been resolved.
Это при том, что update-index вообще-то предназначен совсем для другого.
Вот несколько моментов. Однако, я намерен избавиться от Git’а очень скоро. Я не хочу больше возиться с такой непонятной штукой. Потому, как мержить придется часто и я не хочу, чтобы это было так тяжело.
Eventune
Firefox
Gentoo
Gnome
Google
Songbird