Особенность статей о git’е
Заметил одну интересную особенность статей о Гите — каждая из них рассказывает о формате его репозитория, в который раз талдыча про его простоту и понятность, в то время как статьи про Меркуриал и Базар содержат более близкую пользователю информацию.
Похоже, всё потому, что с интерфейсом Гита просто невозможно справиться, не понимания в точности, что же происходит. В то время как в Меркуриале эта информация избыточна — всё достаточно просто и без того. :)
Add post to:
Comments
Да ладно вам. Git GUI, который идет в стандартной поставке, достаточно неплох — все просто и понятно. В нем даже можно увидеть дерево версий и все пересечения брэнчей. И это абсолютно не требует ни каких знаний о его внутреннем устройстве. Ну если не считать предложение о сжатии репозитория при каждом запуске Git GUI. Я искренне не понимаю почему эту процедуру нельзя проводить автоматически.
А на счет статей вы правильно заметили, очень редко они объясняют как сделать какую-то конретную вещь.
Просто Гиту нужно сделать интерфейс по проще и тогда люди к нему потянутся!)))
Да нормальный у git интерфейс. Уже некоторое время пользуюсь, все достаточно удобно. Как устроен репозиторий, до сих пор имею лишь отдаленное представление, да и то ни разу не пригодилось.
Ну так, с натяжкой… Довольно противный после меркуриала.
У меркуриала мне не понравилось то, что для создания ветки нужно делать где-то сбоку клон репозитория. При моем стиле программирования это несколько неудобно.
Ты похоже не совсем правильно понял. Ветки в меркуриале присутствуют точно так же, как и в гите, только у них нет имён (хотя сейчас есть определённая движуха на тему того, чтобы их добавить). И их точно так же можно пушить отдельно (а не полностью весь репозиторий) с помощью
hg pull -r id_of_head, и ребазировать с помощью mq. Но тут такая штука, что меркуриал меньше на такой режим работы ориентирован, и пока это не сильно удобно (хотя есть надежды, что скоро это поменяется).А так я одно время пользовался плагином Local Branches, хотя подходец немного грязноватый, конечно. :)
Вот вот, они просто разные. Это точно так же, как vim и emacs. Оба вроде тексты редактируют, но одним больше нравится первый, другим — второй.
http://zorgg.blogspot.com/2008/06/blog-post_30.html
В точку. Почему-то с джитом нужно непременно вникать в то, как он устроен и как работает. А с Hg можно сосредоточиться на том, что хочешь сделать. Поэтому предпочитают hg.
Эхех… я, конечно, немного придираюсь к словам, но для меня джит — это JIT, just-in-time compiler. :-)
А некоторые предпочитают гит… Но из всех его фич мне лично не хватает упомянутых выше именованных веток. А так да, hg рулит. :)
Нууу… в целом понимание работы любого механизма — неважно какого — сделает работу с ним проще. И это даже к газонокасилкам относится с той лишь разницей, что все мы и так прекрасно знаем их устройство.
Гит — явно не дурак, с несколько иными приоритетами. Лично мне гуя вообще не нужна, либо очень редко (и базаровские gui-коммандочки тут аж прям в яблочко =)), зато я бы очень ценил скорость (хотя если честно, если в базар запихнуть всю джангу — то статус всех файлов (включая уйму .svn/*) вышвыривается за полсекунды или около того.
Проблема номер два — для оценки этих вещей с ними надо поработать весьма долгое время. По поводу той же скорости — я например не могу с уверенностью сказать что буду доволен базаром (у меркуриала сейчас примерно такая же производительность. Или чуть шустрее =)), когда буду зеркалить нечто с парой тысяч каммитов. Хотя. Взять и проверить. Чего это я… =)
Я вот гит люблю за его хирургическую точность. В меркуриале и базаре все спешат. То и дело вылезают либо уж ОЧЕНЬ спорные моменты в архитектуре, либо с версии 1.3 до 1.5 API меняется с ног на голову (базаар), а потом с 1.5 до 1.6 обратно с головы в ноги (опять базар). В гите это всё отточено. Потому и обсуждают они это много. Потому и рассказывают и пишут — тоже много. В базаре же внутри я видел достаточное количество моментов формирующих в голове мысль примерно следующего содержания “вот тут мы быстренько слепили, вроде шустро работает”. А может у автора и вовссе мыслей не возникало, ибо при чуть чуть изменённом окружении, скажем, сотне бранчей в папке, вместо ожидаемых 10 — всё просто встаёт.
Так что — главное выбрать правильную тулзу для задачи. Хорошо что есть и базаар и меркуриал и гит. Вот это — 100% =).
Ну, чисто для прикола, чекаут джанги с hg.dpaste.com:
Я работал с проектом на ~10500 коммитов (сейчас там уже ~12 тысяч, ЕМНИП), и всё было более чем отлично. Первый чекаут с нуля с сервера в Лондоне проходил за несколько минут, быстрее, чем чекаут в Subversion. =)
Базар, больше 20 раз поменявший формат репозитория, вообще стрёмная штука, и говорить что-то о его стабильности сложно. :) Меркуриал, как и гит, делал это один раз пока, ну и не могу сказать, что там всё тяп-ляп сделано, нету такого ощущения. Мэтт, похоже, вообще чувак довольно основательный.
Базар это все же поле для экспериментов. И по крайней мере форматы бранчей конвертятся между друг другом одной коммандочкой. Я говорил даже не о формате бранчей, а о общем api для работы с ними через питон. Есть ведь до фени внешних утилит, но больше всего раздражает, конечно, когда нужно то и дело допиливать trac-bzr (а с ним и у меркуриала не все хорошо.. даже у тебя на byteflow траке =)).
мммм… я о полном зеркале говорил а не о чекауте… но сча проверимс:
Полное зеркало джанги с launchpad (упёрлись в ширину моего канала и.. lauchpad все же великий тормоз)
Вот последний чекаут показывает как раз голую скорость — распаковку последнего чекаута без сетевых соединений. Кстати. Я про полсекунды говорил все же голый статус на дереве с svn инфой!
Мда… каждую неделю апдейчу джангу в базаровском бранче и даже почти в яблочко угадал сколько времени статус делается (: Опыт не пропьёш..
На самом деле статус — это почти голая производительность фс и кеша ос.
Вон — svn в 4 раза кол-во файлов увеличивает.. и в 10 (!) раз кол-во папок. По крайней мере с точки зрения базара (:
Опять же — скорость чекаутов практически не зависит от формата репозитория — один фиг по сети будет передаваться 100% объём последней ревизии + какое-то количество сопутствующей инфы (размер которой становится все менее критичен при увеличении проекта =)). А вот полное зеркало — тут уже интереснее. В базаре есть даже эксперимент с полным инкрементивным форматом. Но тут возникает второй трабл — если тысячу коммитов собирать диффками даже для 1 файла — это, черт побери, долго. Зато сам репозиторий получается ничтожным по размерам в сравнении со всем остальным =).
Тем не менее я не хочу ни одну систему ставить выше другой. Опыта работы с bzr у меня поболе чем с меркуриалом и ещё более чем с гитом. Одно могу сказать точно — централизованные vcs — нафик! ))
Но… поразмышляй:
(: сейчас устал. Завтра ещё все это прогоню через меркуриал, если ты не поспособствуешь =))
p.s. bzr —version: 1.5
Не, у меркуриала с ним всё отлично, а у byteflow всё поломалось, потому что мне очень хотелось увидеть http://hg.piranha.org.ua/ с темой paper, и потому меркуриал у меня там — свежее не бывает. :) А TracMercurial следует за релизами, естественно.
Я тоже. Я ж показал, сколько там ревизий. ;)
Нужно учитывать, что винда и оно несколько медленнее работает.
Ты плохо воспринял моё слово “чекаут”. Check out — стащить, нафиг. ;) Стащить в меркуриале можно только всё полностью.
Вот именно, что я показывал полное зеркало. 5632 ревизии. Это только trunk, естественно.
.hgсам весит 16 692 kb, вместе с working copy — 29 596 kb. :-)Это TortoiseHg 0.4rc1
и всё-таки папок .svn у тебя ведь нет, раз ты тащил джангу с зеркала hg.dpaste.com (:
проверь с ними, чтоб у тебя ~4500 файлов получилось у джанги. Хрен с ними с ревизиями (теперь зато буду знать что в джанге есть толлько 1 вариант чекаута… у базара — три (:
А, таки нету .svn.
Ну, одним из GSoC-проектов для меркуриала сейчас как раз и является частичный чекаут. Посмотрим, что там выйдет.
Comment form for «Особенность статей о git'е»