Mercurial vs Git

ревизии, в которых мержи затрагивали файл foo/bar

git log --merges foo/bar

ревизии со словами 'bug' или 'issue' в лог-мессагах, не входящие ни в какую помеченную ревизию

git log --max-parent=1 | grep -E '/bug|issue/'

(насчет 2го не уверен, команды не проверял)

ревизии со словами 'bug' или 'issue' в лог-мессагах, не входящие ни в какую помеченную ревизию

git log --max-parent=1 | grep -E '/bug|issue/'
не уверен, команды не проверял)

Если man git-log мне не врет, то --max-parent - это уже неправильно, у меня в примере такого ограничения нет; и не вижу, чтобы ограничение «не входящие ни в какую помеченную ревизию» как-то учитывалось.

Они по сравнению с гитхабом, мягко говоря, жидковаты.

Если man git-log мне не врет, то --max-parent - это уже неправильно, у меня в примере такого ограничения нет; и не вижу, чтобы ограничение «не входящие ни в какую помеченную ревизию» как-то учитывалось.

я поэтому и написал, что не уверен. может быть неправильно. особых усилий к поиску не прилагал (оно мне надо?). я пытался общий принцип продемонстрировать.

теперь можешь ответить, чем он тебя не устраивает?

теперь можешь ответить, чем он тебя не устраивает?

Мне не нравится идея писать на шелле однострочник строки в 3-4 ради того, что выражается в полстроки специального языка запросов.

однострочник строки в 3-4

в фортунки однозначно

выражается в полстроки специального языка запросов

дело вкуса, привычек, задач и самому себе придуманных проблем.

дело вкуса, привычек

Так можно вообще обо всем сказать.

придуманных проблем.

Если выяснить, какие фиксы еще не влиты в релиз - это надуманная проблема, okay.

Mercurial vs Git

Какая свежая тема. man поиск

www.linux.org.ru/search.jsp?q=mercurial git

Да, гит такого не умеет.

Именно поэтому Mercurial рулит. Не раз пользовался бандлами - всё легко и просто в Mercurial. Мне даже не понадобилось читать маны - всё просто отработало как часики.

А git = гемор и бесконечное рытьё в манах и гугление. Но для скачки из сети каких-то исходников - git сойдет, но не для личного пользования.

А совместная работа над проектом в локальной сети или посредством USB флэшек - идеально просто и удобно в Mercurial...

Они по сравнению с гитхабом, мягко говоря, жидковаты.

Существование bitbucket с бесплатными приватными репами с безлимитным местом тоже сыграло для меня роль. А изменения на битбакет за последний год очень радуют - стало удобнее, приближается к гитхабу.

Они по сравнению с гитхабом, мягко говоря, жидковаты.

У гитхаба уже появились бесплатные приватные репы? :)

А git = гемор и бесконечное рытьё в манах и гугление.

но не для личного пользования.

Напомнить сколько реп и пользователей на GH? Ты просто неосилятор, признай это.

Напомнить сколько реп и пользователей на GH? Ты просто неосилятор, признай это.

Хорошо, я неосилятор. Но Mercurial проще и лучше. И даже идеологически понятнее его принципы, Mercurial - гениальная DVCS дающая полную свободу.

Кого волнуют нищебродопроблемы? На гитхаб идут ради социалки.

Кого волнуют нищебродопроблемы? На гитхаб идут ради социалки.

Подобная функциональность появляется и на bitbucket. В будущем планирую платить за учетку на bitbucket, но пока нет необходимости.

Это как фейсбуковконтакты, после того как на рынке есть ктото с 90% потенциальных пользователей добавляй не добавляй ничего не поменяется.

Для единоличного пользования git тоже удобен, можно даже позволить себе делать некошерные вещи

На гитхаб идут ради социалки.

Программисты и социалка — это такая очень хитрая смесь, да :D

Кого волнуют нищебродопроблемы?

А ты из тех, кто предпочитает купить ботинки за $400, когда есть такие же за $150? :)

А git = гемор и бесконечное рытьё в манах и гугление

Напоминает мне сравнение офтопика с никсами: в офтопике все легко и просто, в линухе гемор и бесконечное рытье в мануалах и гугление.

Зато когда просекаешь фишку, все становится офигенно удобно, и ты можешь с презрением смотреть на мучения вантузятников

Нет, на этот раз всё не так. Mercurial сопоставим с git по возможностям, которыми я вообще пользуюсь, но реально проще.

Скажите, Вы пользуетесь Mercurial? Если да, мы с Вами прекрасно понимаем что git-враги говорят ересь относительно hg ^_^

Мне проще git, в mercurial нет многих возможностей, которыми я пользуюсь, и вообще негров линчуют^W^Wcheckout revert'ом делают :)

список? может в Mercurial что-то решается иначе, но проще?

Скажите, Вы пользуетесь Mercurial?

Да я и Mercurial использую, и GIT :) Но для своих проектов — первый.

например, правка коммитов. в hg есть только через плагин (что наводит на сомнения в наджености это кода), к тому же варианта использования только два: стирать старый вариант коммита или хранить его вечно, в гите же эта проблема решается с помощью gc

Шлёпни второй коммит с исправлением - неужели большая беда? :)

Потом на эти коммиты будут люди смотреть, а может и бискетить. Зачем усложнять им жизнь?

Еще в hg нельзя закоммитить только часть изменений в файле

И к тому же правка - не только исправление, это еще и объединение связанных коммитов, и отделение несвязанных правок

Такое расширение тоже есть для Mercurial.

http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ - см «Rewriting history»

Возвращаясь к топику, в любом случае, нужно ли это небольшое группе разработчиков? Неужели каждый должен отрастить себе очки и свитер как у Линуса чтобы просто пользоваться DVCS у себя в конторке?

У себя в котнорке ты можешь хоть rcs использовать, не вижу проблемы

Почему git больше распространён, если он только для огромных команд и зверской автоматизации? Ведь есть много маленьких команд, которым был бы удобнее Mercurial. Что-то тут нечисто...

Если git подходит для работы в большой команде, очевидно, что и для чего-то менее масштабного он тоже подходит.

В мои проекты чужие люди пишут багрепорты и шлют пулреквесты. А на битбакете можно только пофапать насчет экономии 15 баксов.

А rename в mercurial все такой же кривой и плодит копии данных внутри репозитория?

При переносе 100Mb тестовых файлов в другую директорию распухал раньше ровно на 100Mb.

В мои проекты чужие люди пишут багрепорты и шлют пулреквесты

Те проекты, в которые людям имеет смысл писать багрепорты и реквесты — они у меня все открытые :)

Не знаю про rename, а вот move'ом постоянно пользуюсь. Ничего не распухает.

При hg mv внутри .hg создается совершенно отдельная копия данных для файла, т.е. данные дублируются.

Один трамвай зелёный, а другой в парк, да.

А rename в mercurial все такой же кривой и плодит копии данных внутри репозитория?

Да.

При переносе 100Mb тестовых файлов в другую директорию распухал раньше ровно на 100Mb.

У вас тестовые файлы - фильмы и музыка?

Если git подходит для работы в большой команде, очевидно, что и для чего-то менее масштабного он тоже подходит.

Ни разу не очевидно (а в общем случае это заявление просто ложно), man scale down.

У вас тестовые файлы - фильмы и музыка?

Несколько тысяч тестовых сценариев в текстовом виде, внутри сложных тестов куча геометрических данных. Вместе с тестом в файле хранится и текущее решение, соответствующее коду.

Это должно хорошо сжиматься - не понимаю, как переименование 100 метров файлов вызвало рост репозитория на 100 метров.

Но проблема с переименованием есть.

100 метров файлов

Это размер внутри .hg для директории с файлами, в распакованном виде в рабочей копии там все больше в несколько раз занимает. Внутри .hg эти тесты больше половины занимают, поэтому при простом переносе тестов в другую директорию весь репозиторий сильно распухал.

версия Mercurial какая? вы точно hg mv использовали?

кроме того у Mercurial есть hg addremove --similarity что аналогично поведению git-а

Mercurial поддерживает переименовывания, не представляю как вы там перемещали что распухал .hg

версия Mercurial какая? мы точно hg mv использовали?

Версия любая (хотя недавно снова были разговоры об исправлении, в ченджлогах ничего такого нет). Это старая проблема, которую мало кто замечает (ибо юзкейс редкий).

Mercurial поддерживает переименовывания

Внутри оно реализовано как «hg cp + hg rm» (и у Мэтта явно были веские резоны для этого).

А в чем отличие от hg для малых команд?

Выбор hg/git, вообще, чистой воды вкусовщина. Для меня это:

1. git выглядит мощнее в плане управления коммитами, что может пугать, если забыть про revlog.
2. stgit также мощнее mq, например, я не смог понять, как в mq можно работать с несколькими очередями на разных ветках.
4. подкупает простота организации хранилища git, как оно устроено объясняется буквально на пальцах.
5. наличие github :)

У меня Mercurial 2.0.2, сейчас проверил на сжатом бинарнике, реально растет в два раза =( Проблему подтверждаю, что ж я буду врать что проблемы нет.

Но в недрах hg поддерживает переименовывание, возможно просто баг, потому что внутрях .hg реально будто просто удален старый файл и добавлен новый.

Надо бы последнюю версию потестить... Соберу как-нибудь из сорсов...

1. git выглядит мощнее в плане управления коммитами, что может пугать, если забыть про revlog.

Что такого в «плане управления коммитами» умеет git, чего не умеет mercurial или mercurial+mq? И в каких случаях это полезно?

И revlog - это внутренняя структура данных Mercurial, а в git - reflog.

2. stgit также мощнее mq,

Пусть так. Но интересно, сколько процентов гитоюзеров о нем хотя бы слышали.

я не смог понять, как в mq можно работать с несколькими очередями на разных ветках.

...в одном рабочем каталоге, да?

4. подкупает простота организации хранилища git, как оно устроено объясняется буквально на пальцах.

«Ты только думаешь, что понял это» (ц)

5. наличие github :)

Не фактор вообще, по крайней мере для меня.

Кстати, что было пунктом 3?