Меркуриал

[metaclass]

Одной вещи в меркуриале я в принципе понять не могу.
Я меняю файл А, делаю commit и push, потом я меняю дома файл Б и делаю commit, а на попытку push меня посылают фпень делать pull/merge/commit.
Вопрос - почему бы независимые изменения в разных папках не мержить автоматом, как это сделано в svn?

PS: А теперь рассмотрим, как это положено делать:
1) дерево исходников представляет собой граф, узлы которого - каталоги и блобы с файлами, а связи - связь между каталогом и расположенными в нем подкаталогами и файлами.
2) пользователь 1 меняет файл с путем A
3) пользователь 2 меняет другой файл с путем B.
4) Друг другу они в принципе никак не мешают - структура графа не меняется, меняются два независимых узла.
5) операции коммутируют - т.е. вне зависимости от порядка применения операций, результат будет одним и тем же.
6) для коммутирующих операций merge должен делаться, очевидно, автоматически.

Comments

[metaclass.livejournal.com]

Ясно, в коммутирующие операции разработчики DSCM не умеют.

[kiryl.livejournal.com]

git pull --rebase на втором спасает. оно перепишет тебе локальную историю поместив твои коммиты на последний коммит откуда пуллишь. Переписывать историю не стоит, если твой репозиторий публичный. Тогда нужно fetch, merge, push.

[nicka-startcev.livejournal.com]

пиздец.

[kiryl.livejournal.com]

содержательный ответ, да.

[nicka-startcev.livejournal.com]

ну, эта,
"Q: нам надо сходить в соседнее здание за хлебушком.
A: купите самолёт, оплатите аэродромный сбор, купите топливо, прилетите в соседний город, пройдите таможню, купите там. Потом опять топливо и сбор, потом такси."

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

[kiryl.livejournal.com]

Свинья в апельсинах. Очень правильный аватар.

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

[cottidianus.livejournal.com]

браво

[avnik.livejournal.com]

не надо merge
fetch/rebase/push достаточно для обеспечения линейности истории

[kiryl.livejournal.com]

Перечитайте ещё раз.
git pull --rebase -- эквивалент fetch rebase -- что б делать линейную историю. Если твой HEAD уже публичный и переписывать историю нельзя -- тогда merge.

[avnik.livejournal.com]

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

[kiryl.livejournal.com]

Линус требует противоположного от submainter'ов со следующей мотивацией: если у твое topic-дерево отребэйжено на дерево которое опубликовали 20 минут назад, то ты его нихера не тестировал и оно, возможно, вообще не собирается (были случаи). В merge window для v3.7 посылают деревья которые растут от кого-нить v3.6-rc2.
И линейность истории апстрима как самоцель -- сомнительна.

[avnik.livejournal.com]

в описаном тобой случае -- merge осмысленен.
В описаном ребе матакласом случае -- осмысленен ребейс, а мерж зло -- потому что будет засирать историю мерж коммитами.
Когда в проекте 10 комиттеров, а цикл сборки/тестирования занимает от силы 10 минут отребейсить на новый мастер тупо дешевле.

[metaclass.livejournal.com]

Интересно, умеет ли rebase меркуриал. Потому что меня слом линейности и merge коммиты бесят больше, чем необходимость этот merge делать.

[gds.livejournal.com]

умеет.
Зря merge бесят, однако.

[vaddimka.livejournal.com]

там таки есть какая-то черная магия, если хочется чтобы изменения были видны в том же гиториусе не как мержи, а именно как коммиты
фактически получается что надо заребейзиться на remote HEAD, и тогда локальные изменения допишутся "в конец" (т.е. станут straight-forward, или как их там)