metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-11-10 09:41 pm

Меркуриал

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

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

[identity profile] kaa-mmf.livejournal.com 2012-11-10 06:57 pm (UTC)(link)
м-м-м, может я чейта не понимаю, но если последний пуш был от тебя, то никаких доп. приседаний при след. пуше не надо

[identity profile] avnik.livejournal.com 2012-11-10 07:04 pm (UTC)(link)
Я могу объяснить на пальцах -- почему гит тебя пошлет мержить. А тут -- хрен его знает. Корни проблемы те же я подозреваю

[identity profile] metaclass.livejournal.com 2012-11-10 07:10 pm (UTC)(link)
Пуш от меня, но с разных рабочих мест.

[identity profile] metaclass.livejournal.com 2012-11-10 07:11 pm (UTC)(link)
git тоже пошлет? Как они задолбут.

[identity profile] kiryl.livejournal.com 2012-11-10 07:21 pm (UTC)(link)
это distributed scm, детка.

[identity profile] avnik.livejournal.com 2012-11-10 07:22 pm (UTC)(link)
git push:
1 проверяет каких объектов _вниз_ от commit object который ты пушишь нет на сервере, и копирует их туда
2 переписывает ref если старый ref есть в истории того что ты пушишь. (если у тебя push -f -- то просто тупо переписывает реф)
(btw pull ведет себя аналогично)

Ты хочешь чорную магию, а ее там нет.

[identity profile] nivanych.livejournal.com 2012-11-10 07:46 pm (UTC)(link)
Должна быть!!
Это же современные технологии!!

[identity profile] metaclass.livejournal.com 2012-11-10 07:49 pm (UTC)(link)
Ясно, в коммутирующие операции разработчики DSCM не умеют.

[identity profile] kiryl.livejournal.com 2012-11-10 08:01 pm (UTC)(link)
git pull --rebase на втором спасает. оно перепишет тебе локальную историю поместив твои коммиты на последний коммит откуда пуллишь. Переписывать историю не стоит, если твой репозиторий публичный. Тогда нужно fetch, merge, push.

[identity profile] nicka-startcev.livejournal.com 2012-11-10 08:21 pm (UTC)(link)
пиздец.

[identity profile] kiryl.livejournal.com 2012-11-10 08:21 pm (UTC)(link)
> PS: А теперь рассмотрим, как это положено делать:

Ты упускаешь важную часть графа. Про mercurial не скажу, в git оно выглядит так: есть четыре вида объектов: blob, tree, commit, tag. Все объекты адресуются по содержимому -- хэш от содержимого.

Что содежит blob понятно. tree -- список ссылок на blob'ы и другие деревья. Таким образом строится иерархия. commit -- ссылка на корневое дерево проекта, commit message + нуль или более ссылок на parent commit (больше 1 для merge commit). tag -- ссылка любой объект, чаще всего commit.

Из вышесказанного очевидно, что изменение одного blob'а повлечёт к изменению всех объектов выше по стеку: blob -> tree -> commit -> tag.

Т.е. операции не коммутирующие. И это сделано намеряно. Для distributed scm критически важно лёгкое отслеживание целостности, дабы избежать code injection и прочие проблемы с безопастностью.

[identity profile] kiryl.livejournal.com 2012-11-10 08:22 pm (UTC)(link)
содержательный ответ, да.

[identity profile] avnik.livejournal.com 2012-11-10 08:28 pm (UTC)(link)
не надо merge
fetch/rebase/push достаточно для обеспечения линейности истории

[identity profile] kiryl.livejournal.com 2012-11-10 08:31 pm (UTC)(link)
Перечитайте ещё раз.
git pull --rebase -- эквивалент fetch rebase -- что б делать линейную историю. Если твой HEAD уже публичный и переписывать историю нельзя -- тогда merge.
Edited 2012-11-10 20:35 (UTC)

[identity profile] avnik.livejournal.com 2012-11-10 08:35 pm (UTC)(link)
Ребе упускает из вида, что у нас есть еще C -- сервер.

4/5 - ломает, ломает порядок коммитов: будет ломать ребейс. Будет появляться лишний merge сщььше на C которого нет ни на A ни на B

[identity profile] nicka-startcev.livejournal.com 2012-11-10 08:35 pm (UTC)(link)
ну, эта,
"Q: нам надо сходить в соседнее здание за хлебушком.
A: купите самолёт, оплатите аэродромный сбор, купите топливо, прилетите в соседний город, пройдите таможню, купите там. Потом опять топливо и сбор, потом такси."

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

[identity profile] kiryl.livejournal.com 2012-11-10 08:36 pm (UTC)(link)
да, и в merge коммит можно при желании положить какой угодно код.

[identity profile] kiryl.livejournal.com 2012-11-10 08:39 pm (UTC)(link)
Свинья в апельсинах. Очень правильный аватар.

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

[identity profile] voidex.livejournal.com 2012-11-10 08:39 pm (UTC)(link)
Не должен. Если A' + B работает, и A + B' работает, не значит, что A' + B' будет тоже работать, пусть программист об этом знает и ручается.
Смержит он сам, достаточно pull+push.

[identity profile] avnik.livejournal.com 2012-11-10 08:41 pm (UTC)(link)
HEAD публичного ребейсить нельзя да, но свои ветки ребейсить к публичному мастеру можно и нужно. В большинстве проектов где я что-то коммичу, запрещено пушить merge коммиты, они нарушают линейность истории. (исключения есть -- это как правило форки чужих проектов, и merge с апстримом фиксируется в истории)

[identity profile] kiryl.livejournal.com 2012-11-10 08:50 pm (UTC)(link)
Линус требует противоположного от submainter'ов со следующей мотивацией: если у твое topic-дерево отребэйжено на дерево которое опубликовали 20 минут назад, то ты его нихера не тестировал и оно, возможно, вообще не собирается (были случаи). В merge window для v3.7 посылают деревья которые растут от кого-нить v3.6-rc2.
И линейность истории апстрима как самоцель -- сомнительна.

[identity profile] avnik.livejournal.com 2012-11-10 08:59 pm (UTC)(link)
в описаном тобой случае -- merge осмысленен.
В описаном ребе матакласом случае -- осмысленен ребейс, а мерж зло -- потому что будет засирать историю мерж коммитами.
Когда в проекте 10 комиттеров, а цикл сборки/тестирования занимает от силы 10 минут отребейсить на новый мастер тупо дешевле.

[identity profile] max630.livejournal.com 2012-11-10 09:27 pm (UTC)(link)
бгг

Обычно это делается так: пользователь A заводит merge request, потом пользователь B делает review изменений и заставляет A исправить ошибки. Потом специальный человек, когда у него дойдут руки (примерно раз в несколько дней), собирает эти реквесты и мержит (или ребейзит) их в мастер, при необходимости дёргая A чтобы он поправил конфликт.

А вы, ну я не знаю, смиритесь наверное. Или наколхозьте автомержилку на сервере.

[identity profile] djuffin.livejournal.com 2012-11-10 09:46 pm (UTC)(link)
Чтобы программист знал, что были изменения и деклорация метода который он вызвает была удален из совершенно независимого файла.

[identity profile] kaa-mmf.livejournal.com 2012-11-10 10:39 pm (UTC)(link)
а-а-а, ну таки да, это многое меняет...

Page 1 of 4