Mercurial - склейка коммитов

1. Не надо склеивать коммиты, хрен разберёшься потом.

2. Команда может девелопить набор патчей в Mq, потом кто-то делает
`qfold`, а затем `qfinish`.

MQ. Директория с патчами может быть обычным репозиторием, отсюда и плясать.

Конечно, mq.

>Без бранчей обойтись можно?

А вот это странно. Суть DVCS в бранчах, их надо любить. Если недавно с сабвершна мигрировал, не пугайся, работа с бранчами меркуриала вовсе не такой ад, как в svn.

Нет-нет, я бранчей не пугаюсь, просто mercurial используется не только по назначению, но и для обучения новичков в течение самого процесса разработки. Написал он кусок, закоммитил, его наставник запуллил, поправил, сделал коммит. Это просто тривиальный пример. Не хотелось бы, чтобы подобные ситуации палились в общем дереве коммитов. А про Mq да, забыл, надо снова посмотреть.

mq с репозиторием патчей чуть более чем полностью удовлетворяет твоим потребностям.

Забавно только, что обучить ньюфагов-перебезчиков с сабвершн работе с mq может оказаться сложнее, чем обучить их работать с именованными бранчами :)

А причем тут подрепозитории? Подрепозиториями называются вещи вроде http://mercurial.selenic.com/wiki/ForestExtension и http://mercurial.selenic.com/wiki/subrepos

Ну и для тех, кто не юзает mq (большая ошибка!), классика: http://mercurial.selenic.com/wiki/ConcatenatingChangesets

>Написал он кусок, закоммитил, его наставник запуллил, поправил, сделал коммит.

А может лучше ли сначала клонировать, затем изменение - коммит, изменение - коммит ..., правка - коммит и т.д., а затем запулить в основной?

Я бы рекомендовал немного подправить схему: ученик использует mq, наставник осуществляет review патча и после этого производится qfin.

Да.

Эх, все никак не дойдут руки до прикручивания к review board демона, который бы проверял почтовый ящик на тему patchbomb и создавал бы ревью-реквесты из них...

>>Написал он кусок, закоммитил, его наставник запуллил, поправил, сделал коммит.

>А может лучше ли сначала клонировать, затем изменение - коммит, изменение - коммит ..., правка - коммит и т.д., а затем запулить в основной?

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

Хм, ну так и в меркуриале мердж -- один коммит. Линейной история делается только если ясно делаешь ребейз (или если не было коммитов в основную ветку, а для слияния используются не именованные бранчи а разные репозитории, но это уже частности).

> Хм, ну так и в меркуриале мердж -- один коммит.

Не совсем, но это не важно. Если захотеть, то так оно и будет. Получается такая схема: новичок в своей ветке коммитит что-то, потом наставник тянет себе, доводит до ума и делает мерж в основную ветку.

Named branches для этого хорошо годятся. Ну и к тому же наставнику ничего не мешает не пулить в свою working dir изменения, а сделать clone из репозитория нуба в свой локальный и потом пуллить в мастер оттуда.

>> Хм, ну так и в меркуриале мердж -- один коммит.

> Не совсем, но это не важно.

Это относилось к "и", а не к "в меркуриале". В гите можно мержем сохранить всю историю.

Ну так и с меркуриаловским мерджем история никуда не денется! Будет обычный граф ревизий с форком и мерджем.

Топикстартер вроде бы хочет, чтобы не сохранилась. По умолчанию-то она как раз сохраняется.

И чем это так плохо? Если человек работает над одной фичей долгое время и делает сотню промежуточных коммитов с откатами то нафига в мэйнлайн сливать этот мусор?

Плохо это или хорошо зависит от автора коммитов и от того, к чему он привык. Для hg есть такой скрипт, работающий на подобии git`овского squash

http://lysevi.blogspot.com/2009/08/hgsquash.html