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

[Portnov]

В гите удаление ветки (git branch -d/-D) удаляет только ссылку из .git/refs/heads. Коммиты удаляются только тогда, когда на них никто не ссылается, да и то не сразу, а только когда запустится gc, а он зовётся довольно редко.

[drBatty]

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

ИМХО концептуально - это одно и тоже. Рабочий каталог - суть отражение ревизии tip, в которой вы что-то можете поменять, а потом выбрать - закоммитить это, или вернуть как было.

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

ну если это
<x = 10;
>x = 20;
то да. А если это большой кусок кода, со своей (неизвестной вам) историей?

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

ну не сохраняйте...

[watashiwa_daredeska]

Рабочий каталог - суть отражение ревизии tip

Хм… Я почему-то из документации понял так, что когда я делаю hg pull, то уменя tip уезжает в голову импортированного репозитория, дальше я текущий каталог обновляю до tip командой hg update tip. В git'е же почти бесполезно делать git checkout HEAD, потому что HEAD — это то, от чего git считает изменения в текущем каталоге. При импорте создается другая ссылка: FETCH_HEAD, но это уже подробности реализации этой операции. Т.е. HEAD в git'е гораздо теснее связан с workdir, чем tip в hg.

ну не сохраняйте...

Насколько я понял, это встроенное поведение.

[watashiwa_daredeska]

ну если это
<x = 10;
>x = 20;
то да. А если это большой кусок кода, со своей (неизвестной вам) историей?

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

[drBatty]

Хм… Я почему-то из документации понял так, что когда я делаю hg pull, то уменя tip уезжает в голову импортированного репозитория

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

дальше я текущий каталог обновляю до tip командой hg update tip.

не. дальше hg update -r последняя/нужная_ревизия.
туда и tip подтянется и файлы обновятся как tip.

Насколько я понял, это встроенное поведение.

я к тому, что такую ветку не обязательно именовать, пусть будет анонимной, или с tag'ом. А уж если вы решили, что это _релиз_, то логично, что все об этом узнают.

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

я как-бы не про глобальные имена, а про то, что мёртвая ветка из git'а удаляется, а это ИМХО плохо. В мёртвой ветке тоже могут быть полезные идеи и куски кода. И не важно, что никто на неё не ссылается - это необязательно.

[kamre]

с одной стороны пять взаимопересекающихся сущностей:
...
с другой стороны только одна:
1. branches

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

P.S. сам уже больше чем полгода с mercurial серьезно не работал, на работе только SVN сейчас.

[sash-kan]

я как-бы не про глобальные имена, а про то, что мёртвая ветка из git'а удаляется

не запускайте gc и набор коммитов, ни привязанный ни к какому тэгу, переживёт тепловую смерть вселенной·

И не важно, что никто на неё не ссылается - это необязательно

если до коммита нельзя добраться по истории, то зачем он нужен-то?

[drBatty]

если до коммита нельзя добраться по истории, то зачем он нужен-то?

откуда вы берёте такие коммиты? специально делаете что-ли?

[sash-kan]

если до коммита нельзя добраться по истории, то зачем он нужен-то?

откуда вы берёте такие коммиты? специально делаете что-ли?

эмм· создание коммитов — это то, чем и занимается пользователь·
ну да, можно сказать, что коммиты он делает «специально»·
мы же не рассматриваем случаи, когда пользователь действует бессознательно·

[watashiwa_daredeska]

не. дальше hg update -r последняя/нужная_ревизия.

А как узнать последнюю нужную ревизию после hg pull?

нет, не уезжает.

Т.е. тут: http://hgbook.red-bean.com/read/a-tour-of-...asics.html#x_5d написано неправильно?

[watashiwa_daredeska]

я как-бы не про глобальные имена, а про то, что мёртвая ветка из git'а удаляется, а это ИМХО плохо.

Если ветка куда-нибудь вмержена, то не удалится. Для прочих случаев, если очень хочется, можно завести «корзину» в .git/refs и даже написать отдельную git-команду (это будет shell-скриптик в несколько строчек), которая будет переносить ветку в .git/refs/trash вместо удаления. Тогда gc не будет удалять коммиты, а ветка не будет путаться под ногами.

[drBatty]

Если ветка куда-нибудь вмержена, то не удалится. Для прочих случаев, если очень хочется, можно завести «корзину» в .git/refs и даже написать отдельную git-команду (это будет shell-скриптик в несколько строчек), которая будет переносить ветку в .git/refs/trash вместо удаления. Тогда gc не будет удалять коммиты, а ветка не будет путаться под ногами.

в mercurial'е для всего этого есть более простое средство - просто клонируем репозиторий локально, и делаем в клоне что угодно. Потом у нас появляется выбор:
1. запушить всё что мы наворотили в основной реп.
2. или прибить и забыть.
ессно, при выполнении п2 возможно использование сущности "корзина", если вам это нужно.
ИМХО это простой и прямой путь - такие операции может и умеет делать ОС, вот пусть она их и делает.
Кстати, этот клон практически не занимает места на диске, ибо hg использует хардлинки, а не копии файлов (когда может).

[drBatty]

создание коммитов — это то, чем и занимается пользователь·
ну да, можно сказать, что коммиты он делает «специально»·

в hg тоже можно сделать параллельную ветку, которая:
1) не имеет общих предков с основной.
2) не имеет потомков, которые слиты от этой ветки и основной.
Только зачем и кому это надо-то?

А как узнать последнюю нужную ревизию после hg pull?

hg heads выдаст список голов.

Т.е. тут: http://hgbook.red-bean.com/read/a-tour-of-...asics.html#x_5d написано неправильно?

не, всё правильно. Там просто несколько иной случай - вытягивается все новые ревизии, и tip устанавливается на новую голову. Это если новую голову можно однозначно указать. У меня разработка разделилась - я пошёл своим путём, а репозиторий - своим. Потому у меня tip остался на месте - мне надо либо продолжать идти _своим_ путём, либо смержить ветки.

[drBatty]

ЗЫЖ здесь: http://hgbook.red-bean.com/read/a-tour-of-...asics.html#x_5d
позиция "наблюдателя" - он имеет доступ только для чтения (или просто ничего не делает), потому у него tip автоматически перемещается. А у разработчика, который пилит свою ветку, tip так и остаётся на его личной ветке. ИМХО вполне логично.

[watashiwa_daredeska]

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

В гите есть то же самое. Как и в любой друтой DVCS, иначе это не DVCS. Но это не всегда удобно.

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

Вот я о том и говорю — в рабочем каталоге одна ревизия, в tip — другая.

ИМХО это простой и прямой путь - такие операции может и умеет делать ОС, вот пусть она их и делает.

А что, gc в hg нету?

1) не имеет общих предков с основной.
2) не имеет потомков, которые слиты от этой ветки и основной.
Только зачем и кому это надо-то?

Оба два сразу бывает редко, а по отдельности бывает. Однако то, что имел в виду sash-kan (нельзя добраться по истории), касается немного другого: добраться по истории можно от одного из refs, переходя от потомков к родителям. Общие предки не имеют значения. Поэтому если есть тупиковая ветка, на которую нет refs, то gc ее уберет. Такие тупиковые ветки могут появляться довольно часто: заброшенные ветки, которые не вмержены, и ссылка на которые удалена.
В этом смысле мне не очень понятно, как в hg живут анонимные ветки и головы — hg вообще что-ль мышей не ловит и хранит весь мусор за всю историю?

позиция "наблюдателя" - он имеет доступ только для чтения (или просто ничего не делает),

Это вообще-то туториал для разработчика. И доступ там вполне себе полный. Хотя смотря куда, конечно. В репозиторий ИЗ которого делается pull — ридонли, а что, в hg еще и от этого поведение pull меняется?

[drBatty]

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

Вот я о том и говорю — в рабочем каталоге одна ревизия, в tip — другая.

ну это исправляется командой hg update. hg pull вытягивает только ревизии, в том числе и ревизию tip. А файлы команда hg pull не вытягивает. Потому и происходит ситуация, когда ревизии и tip изменились, а файлы ещё нет. Эта ситуация эквивалентна той, в который мы меняем файлы, до коммита.

А что, gc в hg нету?

насколько я знаю - нет.
Мало того, единственный путь _удалить ревизию_ - сконвертировать репозиторий в другой формат, где это возможно, и сконвертировать обратно. Удаление истории, как я понял, противоречит принципам hg.

Оба два сразу бывает редко, а по отдельности бывает.

если по отдельности, то gc их ведь не тронет? правильно?

Однако то, что имел в виду sash-kan (нельзя добраться по истории), касается немного другого: добраться по истории можно от одного из refs, переходя от потомков к родителям. Общие предки не имеют значения. Поэтому если есть тупиковая ветка, на которую нет refs, то gc ее уберет. Такие тупиковые ветки могут появляться довольно часто: заброшенные ветки, которые не вмержены, и ссылка на которые удалена.
В этом смысле мне не очень понятно, как в hg живут анонимные ветки и головы — hg вообще что-ль мышей не ловит и хранит весь мусор за всю историю?

ну да. Тупиковую именованную ветвь можно закрыть:

Shell

hg commit --close-branch

А неименованную можно смержить с основной, при этом брать код из основной ветки.

ИМХО это логично - тупиковые ветки часто появляются потому, что проект _пока_ не готов к какой-то фиче. Но, через какое-то время, проект разовьётся, и будет смысл эту фичу реализовать. Удобно использовать опыт, который был наработан в тупиковой ветке.

[drBatty]

Это вообще-то туториал для разработчика. И доступ там вполне себе полный. Хотя смотря куда, конечно. В репозиторий ИЗ которого делается pull — ридонли, а что, в hg еще и от этого поведение pull меняется?

посмотрите на это с точки зрения разработчика: если он сделал что-то для проекта, то логично выполнить hg push, что-бы затолкать новое в репозиторий. Но он делает hg pull. Зачем? Возможно два случая:

1. он ничего не сделал, и просто хотел посмотреть, как продвигается разработка (может он тимлидер, и сейчас будет мержить, либо он разработчик, и сейчас начнёт свою новую ветвь). Именно этот случай рассмотрен в этой части документации, и очень удобно, что tip автоматически перемещается на точку, в которой сейчас находится разработка.
2. он что-то сделал, и желает посмотреть, как его работа согласуется с текущим состоянием проекта. В этом случае, естественно, разработчик хочет, что-бы tip оставался на своём месте, где он его и оставил, а не прыгнул куда-то, по прихоти других разработчиков и тимлидера. Тут разработчик сможет попробовать смержить свои изменения с проектом, и посмотреть, что из этого выйдет. Вот этот случай описан мной.

В обоих случаях содержимое рабочего каталога не меняется, в первом случае оно просто теряет актуальность, и потому требуется выполнить hg update. Во втором случае tip остаётся на месте, как и файлы. Что собственно и должно происходить.

[watashiwa_daredeska]

ну это исправляется командой hg update. hg pull вытягивает только ревизии, в том числе и ревизию tip.

Я говорю не о том, что это ошибка и как это исправляется, а о том, что tip в hg — это какая-то совершенно отдельная сущность, слабо связанная с workdir. В отличие от HEAD в git'е.

если по отдельности, то gc их ведь не тронет? правильно?

Если во втором случае есть якорь, указывающий на эту ветку, то не тронет.

Тупиковую именованную ветвь можно закрыть

Но она все равно останется.

Мало того, единственный путь _удалить ревизию_ - сконвертировать репозиторий в другой формат, где это возможно, и сконвертировать обратно. Удаление истории, как я понял, противоречит принципам hg.

Это слишком жестоко для меня.

ИМХО это логично - тупиковые ветки часто появляются потому, что проект _пока_ не готов к какой-то фиче. Но, через какое-то время, проект разовьётся, и будет смысл эту фичу реализовать. Удобно использовать опыт, который был наработан в тупиковой ветке.

Тогда, в git, не удаляйте ветку, оставьте на потом. Или прицепите её тегом, чтоб под руками не болталась. Или прицепите ее каким-нибудь другим ref'ом, как я выше писал. Никаких проблем. Однако иногда хочется все-таки удалить мусор.

С определенной т.з. git действует по тем же принципам, что и ФС — есть имена (refs), а есть иноды (git'овые objects: commits, trees, blobs). Пока на объект есть ссылка, он жив, когда нет, его удаляют, хотя и не так сразу, как в ФС. Для меня это просто и понятно. Кроме того, это позволяет понятным образом делать «неправильные» вещи. Хоть они и неправильные, но иногда нужны. Например, переписать историю: от простейшего git commit --amend до Git: полное удаление файла из истории

[watashiwa_daredeska]

если он сделал что-то для проекта, то логично выполнить hg push, что-бы затолкать новое в репозиторий. Но он делает hg pull. Зачем?

Это старинная практика, появившаяся задолго до DVCS: предед коммитом сделай чекаут и смержи сам со свежей версией апстрима, а уж потом отправляй. Это тем более актуально в DVCS, по крайней мере в git, потому что git push не дает ничего мержить. Если он не может просто присобачить новые коммиты (так называемый fast forward), то не делает ничего и выдает соответствующее сообщение пользователю.

Кроме того, в DVCS частенько используется стиль работы pull-only. Я с товарищами частенько такое практикую для маленьких проектов: центрального репозитория нет, каждый pull'ит друг у друга. push делается из своего личного в свой же публичный реп (у каждого свой публичный реп). По тому же принципу обычно ведется разработка сообществом на github'е: маленькое ядро команды может иметь push-доступ к «центральному» репозиторию, но эпизодические внешние разработчики, как правило, присылают pull-request'ы, в которых сообщают upstream'овцам о появлении своей доработки и просят за'pull'ить к себе. Настоящий базар, для которого DVCS и задумывались.

Вот этот случай описан мной.

Я, видимо, что-то упустил. Я не вижу разницы в командах, но почему-то в одном случае tip прыгает, а в другом — нет. Телепатический интерфейс?

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

Т.е. при всей своей высокоуровневости hg не предоставляет высокоуровневых команд для pull+merge и pull+update? По сути, аналогом hg pull является git fetch, а git pull = git fetch + git merge. Только git fetch не меняет HEAD, ибо у HEAD своё, совсем другое назначение.

[sash-kan]

watashiwa_darede...
насколько я понимаю логику mercurial:
hg pull == git fetch
hg update == git merge
git pull == git fetch + git merge == hg pull + hg update

а однокомандного аналога git pull в mercurial, насколько мне известно, нет·
(разве что существует какой-нибудь plugin по этому поводу)·

[watashiwa_daredeska]

hg update == git merge

Неа. hg update == git checkout.
hg pull + hg up tip == git fetch + git checkout FETCH_HEAD.

[drBatty]

Я говорю не о том, что это ошибка и как это исправляется, а о том, что tip в hg — это какая-то совершенно отдельная сущность, слабо связанная с workdir. В отличие от HEAD в git'е.

tip это как раз и есть текущая рабочая директория. В репозитории hg. Локально он естественно _может_ быть другим. Например после команды hg pull он(рабочий каталог) сам по себе не обновляется, и надо выполнить hg update. Ну и естественно, после изменения файлов он тоже не переходит в репозиторий, надо hg commit сделать.

Если во втором случае есть якорь, указывающий на эту ветку, то не тронет.

ну а по моему, "якорь" и сам "gc" есть лишние и ненужные сущности :)

Тупиковую именованную ветвь можно закрыть

Но она все равно останется.

да. и это правильно.
ИМХО.

Мало того, единственный путь _удалить ревизию_ - сконвертировать репозиторий в другой формат, где это возможно, и сконвертировать обратно. Удаление истории, как я понял, противоречит принципам hg.

Это слишком жестоко для меня.

а мне нравится.

С определенной т.з. git действует по тем же принципам, что и ФС — есть имена (refs), а есть иноды (git'овые objects: commits, trees, blobs). Пока на объект есть ссылка, он жив, когда нет, его удаляют, хотя и не так сразу, как в ФС. Для меня это просто и понятно. Кроме того, это позволяет понятным образом делать «неправильные» вещи. Хоть они и неправильные, но иногда нужны. Например, переписать историю: от простейшего git commit --amend до Git: полное удаление файла из истории

всё верно. наверное это даже очень удобно при переносе git'а в маздай. Но... Мне не нужен перенос в маздай, а моя ОС и сама с этим всем отлично справляется.

Это старинная практика, появившаяся задолго до DVCS: предед коммитом сделай чекаут и смержи сам со свежей версией апстрима, а уж потом отправляй

ага. но надо-ли это в DVCS? ИМХО - не обязательно. Я, во всяком случае, этого делать не обязан.

[drBatty]

Кроме того, в DVCS частенько используется стиль работы pull-only. Я с товарищами частенько такое практикую для маленьких проектов: центрального репозитория нет, каждый pull'ит друг у друга. push делается из своего личного в свой же публичный реп (у каждого свой публичный реп). По тому же принципу обычно ведется разработка сообществом на github'е: маленькое ядро команды может иметь push-доступ к «центральному» репозиторию, но эпизодические внешние разработчики, как правило, присылают pull-request'ы, в которых сообщают upstream'овцам о появлении своей доработки и просят за'pull'ить к себе. Настоящий базар, для которого DVCS и задумывались.

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

Я, видимо, что-то упустил. Я не вижу разницы в командах, но почему-то в одном случае tip прыгает, а в другом — нет. Телепатический интерфейс?

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

Т.е. при всей своей высокоуровневости hg не предоставляет высокоуровневых команд для pull+merge и pull+update?

дык это две _разные_ вещи. Вовсе не всегда, и даже более чем НЕ всегда я делаю НЕ pull+merge и НЕ pull+update. Потому мне такие команды и ненужны.

git pull == git fetch + git merge == hg pull + hg update

а однокомандного аналога git pull в mercurial, насколько мне известно, нет·

merge и update НЕ включается в hg pull. hg pull всего-лишь вытягивает заданные (все например) ревизии, и в некотором случае переводит tip. В общем случае, нужно выполнить hg update если мы хотим привести содержимое локального каталога к состоянию tip, либо выполнить hg merge, если мы пожелаем слить наш путь разработки с mainstream'ом. Или hg update mainstream && hg merge my_way, если мы желаем развернуть майнстрим так, как желаем мы (конечно, если у нас не "главный" репозиторий, то мы должны ещё и выполнить hg push. Однако, лично у меня вообще нет "главного" репозитория. У меня все главные, и все одинаковые. А в продакшене вообще нет hg. )

Неа. hg update == git checkout.

ну типа того. с той разницей, что checkout переводит некую "главную" ревизию в рабочий каталог, а hg update переводит локальную ревизию tip в него-же. Как я уже говорил, а hg _в принципе_ нет "главного" репозитория, и все попытки его создать, суть костыли.

[watashiwa_daredeska]

tip это как раз и есть текущая рабочая директория. В репозитории hg. Локально он естественно _может_ быть другим.

Ну, т.е. рабочий каталог, tip и репозиторий — это не брат и сестра, а четыре разных человека? :)

наверное это даже очень удобно при переносе git'а в маздай.

Не уловил, при чем тут перенос куда-то?

но надо-ли это в DVCS? ИМХО - не обязательно. Я, во всяком случае, этого делать не обязан.

hg работает абсолютно точно так же, кстати:

pushing to ../hg1
searching for changes
abort: push creates new remote head 9b337cbfee31!
(you should pull and merge or use push -f to force)

Так что никакой разницы тут между git и hg нет, окромя некоторых формулировок.

[watashiwa_daredeska]

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

Да я и не спорю. Однако, это те сценарии, где надо делать pull без push.

Я, видимо, что-то упустил. Я не вижу разницы в командах, но почему-то в одном случае tip прыгает, а в другом — нет. Телепатический интерфейс?

ну типа того. просто так удобнее. вы разве не находите?

Не знаю. У меня нету. Где дают?

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

Это пресловутый «интуитивно понятный» интерфейс с телепатическим add-on'ом, да? Как-то работает, а как — никто не знает и объяснить не может.

Т.е. при всей своей высокоуровневости hg не предоставляет высокоуровневых команд для pull+merge и pull+update?

дык это две _разные_ вещи.

Да я и не спорю. Однако, pull+merge — наиболее часто используемый сценарий. При тяготении hg к реализации частных случаев для каких-то идеальных workflow очень странно, что для этого случая нет одной команды. Для аналога pull+update в git'е тоже нет единой команды.

Вовсе не всегда, и даже более чем НЕ всегда я делаю НЕ pull+merge и НЕ pull+update.

Я даже с трудом могу представить, зачем делать pull, но не делать потом ни merge, ни update, особенно если это случается чаще, чем merge/update.

checkout переводит некую "главную" ревизию в рабочий каталог, а hg update переводит локальную ревизию tip в него-же. Как я уже говорил, а hg _в принципе_ нет "главного" репозитория, и все попытки его создать, суть костыли.

user@localhost

$ ls action1 $ hg pull ../hg2 pulling from ../hg2 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (run 'hg update' to get a working copy) $ ls action1 $ hg up tip 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ ls action1 action2

Какой, нафиг, «в него же»? После hg up tip в рабочем каталоге появляется другая ревизия. И при чем тут «главный репозиторий»? Его и в git'е нет.

[drBatty]

Ну, т.е. рабочий каталог, tip и репозиторий — это не брат и сестра, а четыре разных человека? :)

репозиторий - множество ревизий. Одна из них (tip) соответствует рабочему каталогу. Однако, локальный рабочий каталог может и не совпадать с ревизией tip. Возможны 2 варианта:
1. сам tip уехал в другую позицию, как у другого разработчика, например если мы вытянули ревизию tip у этого другого разработчика. Нужно сделать hg update для того, что-бы каталог стал-бы такой-же как tip.
2. мы сами изменили рабочий каталог. Вероятно следует сделать hg commit, что-бы сохранить новый tip в репозитории.

Не уловил, при чем тут перенос куда-то?

С определенной т.з. git действует по тем же принципам, что и ФС — есть имена (refs), а есть иноды (git'овые objects: commits, trees, blobs). Пока на объект есть ссылка, он жив, когда нет, его удаляют, хотя и не так сразу, как в ФС.

как я вас понял, git выполняет некоторые действия ВМЕСТО ФС. Т.е. подменяет функции ФС. Это удобно, если ФС старинная и не функциональная (как в маздае). Но если ФС достаточно новая, то этого не нужно. Например в hg при создании клона репозитория используются жёсткие ссылки, что позволяет не тратить место для копий. Т.е. работают механизмы ФС.

hg работает абсолютно точно так же, кстати:

pushing to ../hg1
searching for changes
abort: push creates new remote head 9b337cbfee31!
(you should pull and merge or use push -f to force)

Так что никакой разницы тут между git и hg нет, окромя некоторых формулировок.

Это старинная практика, появившаяся задолго до DVCS: предед коммитом сделай чекаут и смержи сам со свежей версией апстрима, а уж потом отправляй. Это тем более актуально в DVCS, по крайней мере в git, потому что git push не дает ничего мержить. Если он не может просто присобачить новые коммиты (так называемый fast forward), то не делает ничего и выдает соответствующее сообщение пользователю.

ну в hg это несколько другой случай - вы попытались удалённо создать новую голову, т.е. удалённо пытаетесь развернуть разработку проекта в другую сторону (точнее создать развилку). Владелец удалённого репозитория видимо будет весьма удивлён, когда ВНЕЗАПНО, его проект пойдёт в другом направлении, и ему придётся сводить концы с концами (мержить Ваш и свой пути). Эта ситуация будет очень неожиданна на удалённой стороне, о чём вас и предупреждают. Однако, если в удалённом репозитории УЖЕ есть ваша ветка, или вы просто продолжаете развивать проект(без новых развилок-голов), никаких предупреждений не будет. Впрочем, если вы знаете что делаете, вы вправе и создать новую удалённую голову ключом -f.

Не знаю. У меня нету. Где дают?

я-же объяснил критерий, как hg определяет, двигать tip, или нет. Если мы просто смотрим на развитие проекта (или по вашей схеме делаем hg pull main перед каждым изменением локального репозитория) - tip двигается как в главном репозитории. Но это не мешает использовать нам свою схему - у нас может быть своя ветка, которую разрабатываем мы сами, и изменения из main мы берём тогда, когда захотим. При этом tip не двигается при hg pull. Другая ветка (не наша) может развиваться и без нас, но нас это не касается. Это очень удобно, особенно в случаях недоступности некоторых репозиториев (в т.ч. и "главного").

Это пресловутый «интуитивно понятный» интерфейс с телепатическим add-on'ом, да? Как-то работает, а как — никто не знает и объяснить не может.

ну... я hg юзаю не очень давно (чуть больше года), потому до уровня Учителя никак не дорос :(
извините... Я стараюсь понять, как пойму - напишу свою хаутушку, как я это вижу. Пока ещё рано. Потому извините, hg в постах от меня - действительно кривой. Но это моя проблема, а не ртути.

[sash-kan]

Это старинная практика, появившаяся задолго до DVCS: предед коммитом сделай чекаут и смержи сам со свежей версией апстрима, а уж потом отправляй

ага. но надо-ли это в DVCS? ИМХО - не обязательно. Я, во всяком случае, этого делать не обязан.

хм·
а что получится в результате у вас и у вашего коллеги, если:
1. он пошлёт в ветку совместно используемого репозитория изменение файла:
-a=1
+a=2
2. вы после этого в ту же ветку того же репозитория пошлёте изменение того же файла:
-a=1
+a=3

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

[sash-kan]

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

весьма интересно·
вы изменяете в копии файл и (внезапно) в исходном репозитории он тоже изменяется…
т.е. работать с этими двумя копиями независимо уже не получится·
какой же в них смысл?

p.s. в git при создании клона локального репозитория по умолчанию делаются хардлинки на файлы в .git/objects, т.е., на то, что действительно неизменяемо, во-первых, и занимает действительно много места (при большой истории), во-вторых·
и, что характерно, оба репозитория получаются _действительно_ независимыми·

[drBatty]

Да я и не спорю. Однако, pull+merge — наиболее часто используемый сценарий.

вы уверены? hg как раз и хорош тем, что можно работать над проектом OffLine, т.е. тогда, когда сделать pull просто невозможно. У вас есть репозиторий за позавчера, и вы с ним работаете. В продакшен результат работы попадёт после завтра, когда связь появится.

Я даже с трудом могу представить, зачем делать pull, но не делать потом ни merge, ни update, особенно если это случается чаще, чем merge/update.

можно сделать pull сейчас, пока есть связь. Но не прерывать свою работу слиянием, работать дальше над своей недоделанной веткой. Когда ветка будет готова, можно её попробовать слить с маинстримом, и если всё будет хорошо - запушить изменения. А можно и не пушить, а просто слить маинстрим со своей веткой, доделать её (свою), а уж потом слить маинстрим со своей.

Какой, нафиг, «в него же»? После hg up tip в рабочем каталоге появляется другая ревизия. И при чем тут «главный репозиторий»?

В вашем примере tip сдвинулся. Он был изначально в позиции с одним файлом, а после вытягивания он стал в следующей позиции с двумя файлами. Как уже неоднократно я говорил, рабочий каталог не изменился, но после hg up tip у вас в нём появился второй вытянутый из другого репозитория файл action2. В данном случае произошло смещение tip на другую ревизию.

tip не двигается, если вы работаете в другой именованной ветке:

$ hg help up
hg update [-c] [-C] [-d ДАТА] [[-r] РЕВИЗИЯ]

псевдонимы: up, checkout, co

обновить рабочий каталог (или переключить
ревизию)

Обновляет рабочую копию репозитория до
указанную ревизию. Если ревизия не
задана, обновляет до оконечной ревизии
(tip) текущей именованной ветви.

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

[drBatty]

а что получится в результате у вас и у вашего коллеги, если:
1. он пошлёт в ветку совместно используемого репозитория изменение файла:
-a=1
+a=2
2. вы после этого в ту же ветку того же репозитория пошлёте изменение того же файла:
-a=1
+a=3

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

1. сначала коллега запушит своё изменение, и оно запушится.
2. потом я изменю свой файл, и у меня появится своя версия.
3а. я не смогу выполнить push, мне скажут: нельзя создать новую удалённую голову (развилку), используйте ключ f.

Shell

$ hg push проталкиваю в /home/ksu/test/hg1 searching for changes abort: push создаст новую голову 6756b152af1b в удаленном репозитории! (you should pull and merge or use push -f to force)

Если я его использую, в удалённом репозитарии будет две головы, мой вариант, и вариант коллеги. Тимлидеру придётся это слить, и в процессе слияния выбрать один из вариантов (или свой написать, или оставить как было).
3б. я могу сделать hg pull, и тогда развилка появится у меня.

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

$ hg glog
@  changeset:   1:6756b152af1b
|  tag:         tip
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Sun Sep 25 22:29:26 2011 +0400
|  summary:     x=-8
|
o  changeset:   0:e58e1d2eb7c3
   user:        drBatty from ksu <drbatty@drbatty.ru>
   date:        Sun Sep 25 22:26:32 2011 +0400
   summary:     begin

Shell

$ hg pull подтягивая из /home/ksu/test/hg1 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) (используйте 'hg heads' чтобы посмотреть головы, 'hg merge' для слияния)

Shell

$ hg glog o changeset: 2:d834bb906c3b | tag: tip | parent: 0:e58e1d2eb7c3 | user: drBatty from ksu <drbatty@drbatty.ru> | date: Sun Sep 25 22:28:18 2011 +0400 | summary: x=17 | | @ changeset: 1:6756b152af1b |/ user: drBatty from ksu <drbatty@drbatty.ru> | date: Sun Sep 25 22:29:26 2011 +0400 | summary: x=-8 | o changeset: 0:e58e1d2eb7c3 user: drBatty from ksu <drbatty@drbatty.ru> date: Sun Sep 25 22:26:32 2011 +0400 summary: begin

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

потом я это сливаю и комментю:

Shell

$ hg glog @ changeset: 3:af3c8d21b620 |\ tag: tip | | parent: 1:6756b152af1b | | parent: 2:d834bb906c3b | | user: drBatty from ksu <drbatty@drbatty.ru> | | date: Sun Sep 25 22:35:20 2011 +0400 | | summary: merge OK | | | o changeset: 2:d834bb906c3b | | parent: 0:e58e1d2eb7c3 | | user: drBatty from ksu <drbatty@drbatty.ru> | | date: Sun Sep 25 22:28:18 2011 +0400 | | summary: x=17 | | o | changeset: 1:6756b152af1b |/ user: drBatty from ksu <drbatty@drbatty.ru> | date: Sun Sep 25 22:29:26 2011 +0400 | summary: x=-8 | o changeset: 0:e58e1d2eb7c3 user: drBatty from ksu <drbatty@drbatty.ru> date: Sun Sep 25 22:26:32 2011 +0400 summary: begin

А теперь можно и запушить в продакшен:

Shell

$ hg push проталкиваю в /home/ksu/test/hg1 searching for changes adding changesets adding manifests adding file changes added 2 changesets with 2 changes to 1 files

Всё очень просто...