Чтобы добавлять сообщения и комментарии, .

@Balancer:
Balancer

О! Нашёл, наконец, работающий вариант двухсторонней синхронизации git <-> mercurial.

github.com

@k0st1x:
k0st1x

— Дорогой,где ты был?
— Мерджил три ветки.
— Странно, но рубашка сухая и совсем не пахнет!
— Дура, мы уже два года как с SVN на GIT перешли.

@Balancer:
Balancer

Есть тут спецы по git и его апологеты-холиворщики? Как вернуть данные и что с ними произошло? :) — linux.org.ru

@Balancer:
Balancer

Кажется, есть шанс счастливо разрешить вопрос Mercurial vs Git :)

Опять же, за последние пару лет hg-git вылизали и он больше не вешается на моих репозиториях, а работает шустро, как и «родной» Git. Версии коммитов, правда, в Git'е оказываются другими, но это не так страшно, пока работаешь в одиночку.

Правда, как-то непонятно в статистике, пишет, что коммитов только 11 в master и 11 в другие бранчи, хотя на самом деле у меня только один master и коммитов тысячи. Но в целом — работает. Можно из привычного Mercurial работать с Git-репозиториями :)

Правда, на одном пушится почему-то только с --force. Ругается, типа: «прервано: pushing refs/heads/master overwrites 04265dac2ea2»

@LittleChris:
LittleChris

jordi.inversethought.com

@k0st1x:
k0st1x

продолжаю экспериментировать с толстыми репозиториями.
дома попытался склонировать репозиторий linux kernet с гитхаба
(делал из под винды)
это пипец, товарищи.
качался очень долго (за час не скачался, пришлось просто оставить на ночь)
утром увидел, что он взялся нормально, но не смог сделать checkout и сам же посоветовал сделать "checkout -f HEAD"
флаг "-f HEAD" помог,

репозиторий весит 1.49 Gb

мне кажется, что git клиент под виндой такой убогий, что не может сделать clone без ошибок.

мб кто-нибудь мне расскажет, может ли git под линухом делать clone Без ошибок? : )

@k0st1x:
k0st1x

попытка залить централизованный репозиторий с исходниками (хрен знает с какой долгой историей) в mercurial — клонирование такого репозитория занимает 30 минут, а смена бранча почти 1 час (диск классический, не SSD).
git вообще не осилил столько гигов.

резюме: dvcs нужно только для хорошо раздробленных проектов и стартапов.
пока непонимаю, как его можно применить в текущих проектах

@max630:
max630

Я немного слоу, но всё-таки кто-нибудь знает решение, позволяющее централизованным людям пользоваться гитом. Мне кажется, если сделать как в stackoverflow.com , и на репозитории будет, например, 50 человек, они могут заебаться если им постоянно придёся пуллить и мержить. Нужна система, которая сама будет мержить (или ребейзить) и пушить, если нет конфликтов, и возможно выполняются ещё пара условий. В принципе, что-то такое на скриптах я могу уже сейчас себе представить, но может есть что-то готовое и если не ентерпрайзное, то хотя бы гуевое?

@k0st1x:
k0st1x

это не просто 3 бранча — это пиздец f3.s.qip.ru

@k0st1x:
k0st1x

отличный скрин сейвер
pcottle.github.io

@max630:
max630

В последнее время сформировался паттерн работы с vcs, который я для себя называю "отстой пены": голова всегда одна, в неё фигачатся мелкие коммиты. В какой-то контрольной точке делаю rebase, формирую из новейшей истории коммиты для экспорта. Их можно расположить последовательно или раскидать на несколько веток, это уже зависит от workflow команды. Потом ветки сливаются и поверх них кидаются оставшиеся коммиты, которые не пригодились — как правило это всякие локальные хаки, в основном для отладки. Ну или недоделанные изменения. Потом всё начинается по новой.

Таким образом я всегда работаю со всеми своими изменениям, своего рода догфудинг.

@Equidamoid:
Equidamoid

Кстати, радости псто. На новом проекте используется git!

@max630:
max630

Перевёл основной репозиторий на работе на гит. Мелочёвка пока на hg.

Задачу "изучить mercurial" на этом можно считать завершённой.

@max630:
max630

Пожалуй, стоит разбавить вопли фанатов svn обсуждением реальной проблемы.

Модель DAG не совсем точно описывает процесс, используемый командами с git и, подозреваю, другими dvcs. DAG предполагает, что каждая опубликованная HEAD — это заявка на единственно правильный конечный результат, и единственное что можно с ней сделать — смержить с другой HEAD, чтобы объединить их достоинства.

В реальности всё не так. У софта бывает несколько параллельных веток, и часто изменение требуется не просто объединить с более новыми правками, продвинув его по истории вперёд, но и спортировать вбок или назад....

@anton0xf:
anton0xf

чтобы в выоде stat и прочих видеть читабельные имена файлов, названных не по русски^Wанглийски, а не заквоченную фигню нужно выполнить:
git config --global core.quotepath false

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

@anton0xf:
anton0xf

а как посмотреть, какая ветка за какой удаленной следит (track)?

@anton0xf:
anton0xf

а в чем профиты от этой их теории патчей и вообще?
линки на статьи приветствуются)
// говоря dvcs, подразумеваю в первую очередь git, как самый привычный и изученный

@max630:
max630

hg для пользовартелей git: небольшой опыт разбирательства по горячим следам
max630.livejournal.com

@Equidamoid:
Equidamoid

Хочется монтировать, скажем, git-репо в каталог, чтобы смотреть файлы, не создавая реальную копию на диске.

@Equidamoid:
Equidamoid

1. Почитать про оба, выбрать один
2. Почитать маны
3. Научиться эффективно пользоваться
4. Перестать трындеть о вспомогательных средствах и начать, наконец, писать чёртов код =)

@Equidamoid:
Equidamoid

Ещё сильнее люблю dvcs, и начинаю любить git...

@max630:
max630

Кстати, а накидайте мне соображений — чем нелинейная история (с мержами) хуже линейной (с rebase). Я пока вижу такие:
* при большом числе параллельно существующих веток плохо визуализируется графически
* несколько маленьких конфликтов (при rebase) проще разруливать чем один большой (при merge)
есть и ещё одна, которую я считаю не оправданной (почему, объяснять лень, может напишу в комментах):
* можно легко ответить на вопрос — что у нас было в master в какой-нибудь момент времени
есть ещё несколько ситуаций, которые принципиально разрешимы, но git в них лажает:
* bisect
* rebase нелинейной истории
Ещё что-то?

@otakuSiD:
otakuSiD

Жуец, а есть тут кто с проектом который юзает DVCS какую (Mercurial аль Git там) и интегрирутся с помощью CruiseControl.NET? Есть вопросец по поводу того как вы номера ревизии для билда проставляете. Они ведь у каждого в репе по своему генерятся, а хеши в качестве версии как то не принято юзать. Как кто эту задачу решает?

На Subversion проблемы небыло. Есть формат {major}.{minor}.{revision}.{build} и номер ревизии из репозитория берется, он уникален у всех. А с DVCS такое уже не прокатит.

@nib952051:
nib952051

подскажите как правильно: куда в репозитории девать конфиги? что лучше игнорить или держать в бранчах, например?

@mirivlad:
mirivlad

Что лучше? mercurial или git?

@Gepard11vvk:
Gepard11vvk

Git How To на русском bit.ly

@Gepard11vvk:
Gepard11vvk

Рекомендую CommitMonitor для SVN (под win) bit.ly

@bader:
bader

Пробую перейти с git на mercurial. Второй день — полёт нормальный. Радует, что bitbucket, в отличие от github, предоставляет бесплатный private репозиторий.

@denver14:
denver14

Устроился как-то Молодой Программист работать в команде вместе со Старым Программистом. Сидит, в проект вникает, код изучает, доки почитывает, в схеме разбирается. Всё спокойно, Старый Программист клепает код, закрывает тикеты, коммиттит ревизии. Но иногда приходит чёрт с молотком и забивает Старому Программисту в жопу гвоздик. Аккуратный такой, обойный гвоздик. И так почти каждый день.

Старый Программист всё это мужественно переносит, иногда только шипит сквозь зубы. А Молодой удивляется. Наконец не выдержал, спросил, в чём, мол, дело.

— Да это заказчик любит иногда сам код писать, — объясняет Старый. — А нашей системой контроля версий не пользуется. Приходится постоянно забирать от него весь проект проверять, что он там поменял.
— А чёрт зачем приходит?
— О, это Мерж. Да ты его не бойся, он не страшный. Мы привыкли уже.

Долго ли коротко ли, дают Молодому Программисту задачу. Вот он вытянул себе последнюю версию исходников, сидит себе работает, доки гуглит, на форумах расспрашивает, фичи реализует, либы прикручивает. Да не смотрит на чужие изменения, не обновляет исходники. А там чудеса происходят, звери дикие гуляют, птицы дивные по веткам прыгают, таблицы рождяются и исчезают, как будто и не бывали.

Рубился Молодой Программист тридцать дней и три ночи, но доделал наконец фичу. Тесты готовы, xUnit зелёненьким моргает, запросы летают аж со свистом. Решил закоммиттить — а не выходит. «Исходники надо подтянуть», — думает.

Только на кнопку pull надавил — дым, грохот, откуда ни возмись Чёрт появляется. С молотком огромным и ведром гвоздей-стопятидесяток:

— НУ ЧТО, ЧУВАК, МЕРЖИТЬ БУДЕМ?

@Yurtaev:
Yurtaev

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

@odin:
odin

gwsmhg — a GUI wrapper for hg and mq gwsmhg.sf.net <gwsmhg.sourceforge.net>

@tsul:
tsul

Ресурсы по Bazaar:
1) site: bazaar-vcs.org
2) Кратко о Bazaar для пользователей других DVCS: hlabs.spb.ru
3) Распределенная система контроля версий Bazaar: hlabs.spb.ru
4) Why Switch to Bazaar? doc.bazaar.canonical.com
5) Workflows: wiki.bazaar.canonical.com
---
технологии:
— Bazaar Patch Queue Manager: launchpad.net
— Bound branches: wiki.bazaar.canonical.com

@tsul:
tsul

Ресурсы по Mercurial: ru.wikipedia.org
1) site: mercurial.selenic.com
2) TortoiseHg: tortoisehg.bitbucket.org
3) Intro to DVCS + Mercurial Quick Start: betterexplained.com

@tsul:
tsul

Ресурсы по git для дальнейшего изучения:
1) маны от AltLinux Team:
— Руководство пользователя GIT (для версии ≥ 1.5.3): freesource.info
— Учебник введение в git (для версии ≥ 1.5.1): freesource.info
2) TortoiseGit: code.google.com , для него нужен Git for Windows: code.google.com

@tsul:
tsul

Изучение и выбор DCVS. Критерии и цели: GPL, переход с Subversion, хороший CLI, понятный GUI в Windows, хотя бы для повседневных задач (как TortoiseSVN), для небольших команд; ну для общего развития:)

@develar:
develar

в тему juick.com GIT круче всех :) за svn в opensource надо сразу кастрировать. hg проигрывает git 1) лично я меньше трахался с установкой и всякими нюансами 2) c svn лучше работает 3) есть более лучшая поддержка — плагин для idea (hg4idea хуже в разы) и gitx (мурка тупо виснет). Но все эти opensource хостинги типа githib/bitbucket унылы — мне даром не нужны ваши социальные фичи, дайте мне нормальный issue tracker/wiki (то что есть, для человека, знающего что такое confluence/youtrack/jira просто не котируется).

@v0id:
v0id

Вчера вышел свежий TortoiseHg под версией 1.1 со свежим же Mercurial'ом 1.6. Рекомендую всем сочувствующим. Качать здесь -> tortoisehg.bitbucket.org

@sergray:
sergray

has been initiated with hginit.com

@sergray:
sergray

обсуждение поста Joel'а о распределённых системах контроля версий в блоге Якова Сироткина yakov-sirotkin.livejournal.com

@advicecat:
advicecat

Решил присмотреться к гиту. По существу пока сказать нечего, но сразу отметил, что после hg st и hg ci как-то лень набирать git status и git commit.