[РЕШЕНО] mercurial (hg) - вытягивание изменений из анонимной ветки

[drBatty]

Что-то запутался:
Есть репозиторий, в нём есть две (анонимные) ветки: например current & release. И соответственно есть 2 не слитых головы:

Код: Выделить всё

@ - current
|
| o - release
| |
|/
|
o

как мне вытянуть изменения из release в current без слияния? (т.е. что-бы так и осталось 2 головы, но изменения из release перешли в current).

[IMB]

hg diff -r1 -r2 > patch

[kamre]

как мне вытянуть изменения из release в current без слияния? (т.е. что-бы так и осталось 2 головы, но изменения из release перешли в current).

http://mercurial.selenic.com/wiki/TransplantExtension

[drBatty]

IMB
не... это не то. я могу сказать hg update -r2 с тем-же успехом.

kamre
спасибо, то что надо.

[sash-kan]

как мне вытянуть изменения из release в current без слияния? (т.е. что-бы так и осталось 2 головы, но изменения из release перешли в current).

http://mercurial.selenic.com/wiki/TransplantExtension

как всё сложно-то… неужели в mercurial нет команды merge?

[drBatty]

как мне вытянуть изменения из release в current без слияния? (т.е. что-бы так и осталось 2 головы, но изменения из release перешли в current).

как всё сложно-то… неужели в mercurial нет команды merge?

есть конечно.

[watashiwa_daredeska]

А разве merge в hg удаляет голову?

[drBatty]

А разве merge в hg удаляет голову?

конечно. merge сливает две головы в одну.

[watashiwa_daredeska]

конечно.

Ужас какой.

[drBatty]

я так и не дождался ответа, и попросту смержил две ветки. Получилась одна. Потом откатился на старую ревизию release, сделал незначительные изменения, закомментил, и опять получилось две головы. Но изменения из release таки перешли в current. Т.е. можно и так делать, только не очень удобно.

Ужас какой.

а как у вас? (где, кстати?)
сливаем две головы в две головы? как-то ИМХО нелогично...

[watashiwa_daredeska]

а как у вас? (где, кстати?)

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

[drBatty]

git merge вливает изменения от общего предка.

ужас какой.
ИМХО mercurial всё-же проще и логичнее. (я НЕ говорил - "лучше"! может и хуже...).

При этом одна голова пополняется (в общем случае, но не всегда) еще одним коммитом,

как я понял, в hg вообще нет "коммитов" в смысле истории проекта, есть ревизии, которые создаются действием-коммитом. Ревизия без потомков и является головой.

[watashiwa_daredeska]

ИМХО mercurial всё-же проще и логичнее.

Ну, это смотря у кого какая логика :)

в hg вообще нет "коммитов" в смысле истории проекта, есть ревизии

Ну, от переименования суть не меняется.

Ревизия без потомков и является головой.

В git «голова» может показывать на коммит с потомками. И это хорошо и удобно. Например, я делаю ветку experiment от текущей головы master и вношу в experiment изменение. Теперь у головы master есть потомок, но голова от этого не перестает быть таковой.

[drBatty]

Ну, это смотря у кого какая логика :)

В git «голова» может показывать на коммит с потомками. И это хорошо и удобно. Например, я делаю ветку experiment от текущей головы master и вношу в experiment изменение. Теперь у головы master есть потомок, но голова от этого не перестает быть таковой.

обычная у меня логика, как IRL: ИЗ головы ничего не растёт. Расти может из тела, или НА голове. Голова - суть окончание чего-либо. А у вас из одной головы растут тушки с другими головами. Вы только представьте себе такой организм IRL! Не страшно?

В hg я из головы master делаю голову experiment, при этом, master перестаёт быть головой - проект движется дальше. Проблема в том, что если найдётся ошибка в master, её надо будет исправить - вернутся к master, исправить ошибку, и выпустить новую версию master2. Так и появляется вторая голова. Если я далее продолжаю разрабатывать голову experiment, мне нужно исправить эту ошибку и там. Однако, предположим, что эксперимент не завершён, и я пока не хочу сливать ветки в одну. Так и появляется необходимость pulling'а изменений из главной ветки в экспериментальную.

Интересно, как решается эта проблема в git'е?

Ну, от переименования суть не меняется.

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

[sash-kan]

git merge вливает изменения от общего предка.

ужас какой.
ИМХО mercurial всё-же проще и логичнее. (я НЕ говорил - "лучше"! может и хуже...).

в чём ужас? это именно то, что вам требовалось·
вам разве «ужас» требовался?

в git команда merge реализует одну из самых базовых функций системы управления версиями·
а в mercurial для этого какой-то плагин требуется·
получается одно из двух: либо mercurial не является системой управления версиями, либо работа этой программы построена на какой-то альтернативной логике·

[watashiwa_daredeska]

Интересно, как решается эта проблема в git'е?

git merge
Ведь при git merge ни master, ни experiment никуда не деваются.

Интересный вопрос, что считать головой :) В git'е, когда я создаю вторую ветку, у меня логически появляется вторая голова, которая пока совпадает с исходной. В каждый момент времени я могу работать логически в ветке master или в ветке experimental. Сначала, это вроде как без разницы — они идентичны, но при коммите у меня изменится та голова, в которой я в данный момент работаю. Т.е., помимо всего прочего, существует еще «текущая голова», HEAD. HEAD может и не совпадать ни с одной из именованных. Например, я решил попробовать ответвить проект от одной из прошлых ревизий, тогда я просто переставляю HEAD на нужный коммит по его hash'у (получается detached HEAD), делаю коммиты и т.п. Если понадобится, можно эту «оторванную голову» как-нибудь назвать, а не понравится, можно просто бросить — сборщик мусора подберет (т.к. не останется ни одного «якоря», который держит эту часть графа коммитов живым).

Таким образом, в git'е голова — понятие логическое, а не физическое. Логически, из головы ничего не растет, а что происходит физически — дело десятое.

[sash-kan]

Так и появляется необходимость pulling'а изменений из главной ветки в экспериментальную.

и, насколько мне подсказывает и мой опыт, и наблюдение за существующими проектами, и здравые размышления, это _очень_ распространённое действие разработчика·
в mercurial оно, оказывается, не входит в базовый набор действий·
что ж, это неудивительно·
вот другое элементарное действие, которое, судя по всему, в mercurial или не реализовано, или реализовано каким-нибудь посторонним средством·

[kamre]

получается одно из двух: либо mercurial не является системой управления версиями, либо работа этой программы построена на какой-то альтернативной логике·

В mercurial альтернативная логика для понятия branch, отсюда и непонимание возникает.

Каждая именованная ветка может иметь несколько heads, т.е. фактически именованная ветка может дальше разветвляться на анонимные ветки. При merge таких анонимных веток пропадает head. Если же делать merge из именованных веток, то разные head останутся.

Так что если у ТС были именованные ветки, то можно было делать merge и обе head остались бы как head. А если это анонимные ветки на основной ветке default, то получился бы один head.

Кроме того есть еще bookmarks, чтобы можно было работать с анонимными ветками почти как с ветками в git. Например, можно было разработки вести на одной именованной ветке default, а для экспериментального коммита выставить bookmark experiment, тогда получилось бы примерно вот так:

Код: Выделить всё

@  changeset:   3:766d9b4c7910
|  bookmark:    experiment
|  tag:         tip
|  parent:      1:bae1b2069b2b
|  summary:     more text added
|
| o  changeset:   2:1b14fba5d36b
| |  bookmark:    stable
| |  parent:      0:4c3b327fc4e3
| |  summary:     added one more file
| |
o |  changeset:   1:bae1b2069b2b
|/   summary:     changed text
|
o  changeset:   0:4c3b327fc4e3
   summary:     added some file

После hg merge -r stable получилось бы так:

Код: Выделить всё

@    changeset:   4:8f77a312d0f9
|\   bookmark:    experiment
| |  tag:         tip
| |  parent:      3:766d9b4c7910
| |  parent:      2:1b14fba5d36b
| |  summary:     changes merged
| |
| o  changeset:   3:766d9b4c7910
| |  parent:      1:bae1b2069b2b
| |  summary:     more text added
| |
o |  changeset:   2:1b14fba5d36b
| |  bookmark:    stable
| |  parent:      0:4c3b327fc4e3
| |  summary:     added one more file
| |
| o  changeset:   1:bae1b2069b2b
|/   summary:     changed text
|
o  changeset:   0:4c3b327fc4e3
   summary:     added some file

Т.е. голова одна, но bookmarks experiment и stable указывают на разные ревизии. Можно сделать hg up -r stable и работать со стабильной версией, хотя эта ревизия stable уже и не голова в ветке default.

[watashiwa_daredeska]

Если же делать merge из именованных веток, то разные head останутся.

Простите, если у именованной ветки несколько head, то что означают слова «merge из именованной ветки»? Из какой головы этого Змея Горыныча будет идти merge?

[watashiwa_daredeska]

делать merge и обе head остались бы как head

Честно говоря, меня не впечатляют такие вариации поведения в зависимости от скрытых свойств аргументов.

Кроме того есть еще bookmarks

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

[sash-kan]

с одной стороны пять взаимопересекающихся сущностей:
1. clones
2. named branches
3. implicit branches
4. bookmarks
5. heads
(первые четыре пункта почерпнуты отсюда)

с другой стороны только одна:
1. branches

сижу и думаю: какая же из сторон более понятна интуитивно?
наверно, всё-таки первая·
для второй достаточно логики, и не нужно обращаться к интуиции…

[drBatty]

в чём ужас? это именно то, что вам требовалось·
вам разве «ужас» требовался?

в git команда merge реализует одну из самых базовых функций системы управления версиями·
а в mercurial для этого какой-то плагин требуется·
получается одно из двух: либо mercurial не является системой управления версиями, либо работа этой программы построена на какой-то альтернативной логике·

на самом деле, это в моей голове проблема, а не в hg. Можно было-бы просто написать hg merge и все дела. Я сам не пойму, ЗАЧЕМ мне понадобилась вторая голова?!
Вот как стало:

Код: Выделить всё

@ - head
| \
o | - current
|  |
|  o - release
|  |
|/
|
o

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

Код: Выделить всё

   @ -new release
   |
o |   - new current
| \|
o | - current
|  |
|  o - release
|  |
|/
|
o

опять стало 2 головы, без всяких плагинов.

и, насколько мне подсказывает и мой опыт, и наблюдение за существующими проектами, и здравые размышления, это _очень_ распространённое действие разработчика·
в mercurial оно, оказывается, не входит в базовый набор действий·

входит. трансплантация сторонним плагином нужна только в _очень_ редких частных случаях.
обычно достаточно hg merge.

Простите, если у именованной ветки несколько head, то что означают слова «merge из именованной ветки»? Из какой головы этого Змея Горыныча будет идти merge?

очевидно из самой свежей.
хотя скорее ошибка будет. я попробую...

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

все эти дополнительные сущности - суть костыли, которые делают из mercurial'а подобие git'а (svn, vss, etc...). их не обязательно использовать IRL. я вот без них обхожусь.

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

вы разве не помните, как я тут спрашивал про конструкцию bash $[EXP]?
она даже в моём man bash не описана. А эта сущность таки используется. Даже в тестах на проф-пригодность. Уверен, в git'е тоже есть такие мёртвые, никому не нужные сущности.
kamre спасибо. уполз читать маны...

[Portnov]

Технически, в git-е нет отдельного понятия «голова». Есть просто некоторое количество ссылок в .git/refs/heads, которые указывают на определённые коммиты. И даже «ветка» — довольно искусственное понятие, хотя и есть в документации к git. Просто у каждого коммита есть один или несколько родительских коммитов. Двигаясь по ссылкам на родителей, можно получить некоторую последовательность коммитов и назвать её веткой.

[drBatty]

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

не... как-то всё несвязанно... ещё и оторванные ветки... ещё и сборщик мусора... жуть...
В hg всё проще - есть ОДНА ревизия без родителей - первая. Все остальные ревизии имеют одного или двух родителей - всё очень просто, и наглядно. Причём ничего не отрывается, и не удаляется. Потому граф всегда связан, и имеет простую топологию (даже в сложных проектах например в firefox)
вот топология самой ртути: http://selenic.com/hg/graph/tip
покажите мне подобное для git'а. я что-то не нашёл...

[watashiwa_daredeska]

В hg всё проще - есть ОДНА ревизия без родителей - первая. Все остальные ревизии имеют одного или двух родителей - всё очень просто, и наглядно. Причём ничего не отрывается, и не удаляется. Потому граф всегда связан, и имеет простую топологию (даже в сложных проектах например в firefox)

Лично мне требовалось склеить два проекта, которые начинались как независимые. Получилось без проблем, в итоге — два коммита «без родителей», точнее, с «нулевым родителем» — он всегда один, не хранится и обычно не показывается нигде.

Вообще, git устроен на удивление просто. Есть граф коммитов. Коммиты находятся под управлением сборщика мусора. Коммиты ссылаются друг на друга (на родителей). Есть «якоря», которые держат некоторые коммиты, чтобы gc их не удалил. На 0-м уровне приближения все «якоря» по сути одинаковы и хранятся в .git/refs. Есть особенная ссылка HEAD — это коммит, на основе которого делается текущая модификация в working dir. Если изменеия working dir будут закоммичены, нынешний HEAD станет родителем нового коммита и HEAD переместится на новый коммит. HEAD можно переставить на абсолютно любой коммит в графе и «наращивать» его с этого места. Кроме того, HEAD можно связать с любым якорем, тогда при очередном коммите этот якорь будет перемещаться на новый коммит. Собственно, на этом всё.

Итого, имеем 4 сущности, которые нужно понимать для работы с git: commit, ref (якорь), HEAD, working dir.

На следующем уровне приближения «якоря» немного различаются: есть heads (для пользователя — branches), есть tags, есть отдельный якорь для stash, есть якоря для импортированных репозиториев (remotes), могут быть еще любые другие, которые создают/используют скрипты пользователя. Пользовательские команды не позволяют связать HEAD с тегом, но низкоуровневые команды позволяют это сделать. Например, после git symbolic-ref HEAD refs/tags/tag git будет обновлять тег tag при коммитах как и любой другой якорь. Собственно, различие проявляется лишь на более высоких уровнях абстракции, которые суть частность для определенного стиля работы. Например, на том же базовом движке git'а построена система для совершенно другого workflow: stgit.

граф всегда связан, и имеет простую топологию (даже в сложных проектах например в firefox)

А зачем нужна простая топология? Почему граф должен быть связан? Мне эти требования абсолютно чужды. Т.е. я, конечно, понимаю — эстетика и всё такое, но если эта эстетика будет мешать мне дело делать, то ну ее в…

[drBatty]

Лично мне требовалось склеить два проекта, которые начинались как независимые. Получилось без проблем, в итоге — два коммита «без родителей», точнее, с «нулевым родителем» — он всегда один, не хранится и обычно не показывается нигде.

дык что мешает в hg просто стереть все файлы в рабочем каталоге (кроме ./.hg*) и скопировать туда второй проект?

Итого, имеем 4 сущности, которые нужно понимать для работы с git: commit, ref (якорь), HEAD, working dir.

в mercurial'е имеем четыре сущности:
1. ревизии
2. головы (оконечные ревизии. они могут иметь потомков в физическом смысле, но в логическом это последняя стадия разработки ветви)
3. рабочий каталог, он-же ревизия-голова tip (после коммита)
4. именованные ветки. в принципе тоже, что и анонимные, только с именем, и как следствие - со своей историей.

HEAD можно переставить на абсолютно любой коммит в графе и «наращивать» его с этого места.

в hg тоже можно перейти к любой ревизии, и развивать её параллельно с основной (если это ревизия не конечная голова, иначе просто продолжится линейное развитие проекта. А так будет ветвление).

Кроме того, HEAD можно связать с любым якорем, тогда при очередном коммите этот якорь будет перемещаться на новый коммит. Собственно, на этом всё.

ну а аналогом якорей видимо являются именованные ветки, которые в своём развитии сохраняют своё имя.

На следующем уровне приближения «якоря» немного различаются: есть heads (для пользователя — branches), есть tags

угу. в hg также.

есть якоря для импортированных репозиториев (remotes)

а вот такого нету, как я понял. Дело в том, что в hg репозиторий - абстракция, и на самом деле есть некий "облачный" главный репозиторий, а локально хранятся только его зеркала.

А зачем нужна простая топология? Почему граф должен быть связан?

для простоты - всегда знаешь, что и откуда взялось. и можно с лёгкостью проследить его развитие. а вот когда у вас ветка удаляется, кодерам видимо сложно понять ваши ВНЕЗАПНЫЕ изменения, ведь их история канула в Лету.

Мне эти требования абсолютно чужды. Т.е. я, конечно, понимаю — эстетика и всё такое, но если эта эстетика будет мешать мне дело делать, то ну ее в…

дело не в эстетике. дело в том, что все изменения появляются не просто так, а откуда-то берутся. пусть даже из мёртвых ветвей. просто по принципам развития RL. как я понимаю, в git'е часть информации теряется, что в любом случае плохо - даже тупиковый путь приносит пользу, хотя-бы потому, что в ртути сохраняются данные об этом тупике, и всегда можно посмотреть, почему мы свернули оттуда, или вернулись назад и пошли другим путём. В git'е, как я понял, в один и тот же тупик можно входить множество раз.

[watashiwa_daredeska]

дык что мешает в hg просто стереть все файлы в рабочем каталоге (кроме ./.hg*) и скопировать туда второй проект?

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

[drBatty]

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

а...

Shell

hg pull project2 -f

потом слияние голов (если надо)
тогда будет не дерево, а лес - два корня. Я проверил - такой вариант вполне работоспособен.

[watashiwa_daredeska]

3. рабочий каталог, он-же ревизия-голова tip (после коммита)

Судя по документации, это совсем разные вещи. Гораздо более разные, чем workdir и HEAD в git'е, которые я разделил как сущности.

аналогом якорей видимо являются именованные ветки, которые в своём развитии сохраняют своё имя.

Нет, не являются. ref в git'е — базис для реализации всего остального. Т.е. появление тэгов, фактически, не добавляет совершенно новой сущности — это ровно та же сущность, совсем слегка модифицированная. ref не накладывает абсолютно никаких лишних ограничений и не добавляет никакого лишнего поведения, а потому пригоден для реализации новых идей и механизмов в дальнейшем.

а вот такого нету, как я понял. Дело в том, что в hg репозиторий - абстракция, и на самом деле есть некий "облачный" главный репозиторий, а локально хранятся только его зеркала.

Ну, абстрактно говоря, можно считать, что в git вообще существует лишь один общемировой репозиторий для всех, а локально хранятся лишь части, зацепленные за «якоря», остальное вычистил gc :) При импорте внешнего репозитория, выкачиваются в локальное хранилище все объекты, зацепленные за запрошенные из него якоря, а для запрошенных якорей создаются локальные обозначения.

для простоты - всегда знаешь, что и откуда взялось.

Что значит, откуда? Я знаю имя человека, от которого получено изменение.

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

Они берутся не из ветвей, а от людей. Ветви — чистейшей воды условность. И сохранять имя ветки в коммите (ревизии) глобально — это вообще противоречит распределенной базарной идее подобных VCS.

[watashiwa_daredeska]

когда у вас ветка удаляется, кодерам видимо сложно понять ваши ВНЕЗАПНЫЕ изменения, ведь их история канула в Лету.

Ведь в комментарии к коммиту же всё написано. И да, другим кодерам названия моих веток могут не сказать вообще ничего.