Для того, чтобы оно работало, нужно только обновиться. «Сделать force существующей ветки» так же, как в git, невозможно — из истории на удалённом сервере нельзя удалить ничего, если только у вас нет там доступа к shell. Сделать rebase, «проигнорировав» фазы можно — сначала помечаете изменения как черновики («phase --force --draft»), затем делаете rebase, затем push (опять с ключом --force). Правда всё, чего вы добьётесь, — это появления новой головы в репозитории. При следующем pull изменения, которые вы якобы переместили, опять у вас появятся. Перемещённые версии, впрочем, тоже сохраняться.
Phases не запрещают стрелять себе в ногу. Они только усложняют нажатие на курок.
Предохранитель — это хуки. Всё, что можно сломать push’ем — это добавить ненужные изменения, которые сможет удалить только администратор. Возможно что при «pull --update» пользователи в результате окажутся на каком‐то не том изменении. Если пользователи — не боты, то в этом ничего страшного нет. Если боты — всегда используйте только «push -f -B {name}»/«push -f -r {rev}», чтобы не отправить что‐то не то (эти команды отправляют только те изменения, которые им указали и их предков, больше ничего).
AuRecord тоже умеет распиливать hunk’и, даже и для subversion, если надо. И для mercurial. Третий аргумент исчезает, если правильно выбрать UI, потому что идея, используемая hg record универсальна и работает для любой VCS, умеющей status и cat-file.
Первый аргумент мне совершенно непонятен — в чём преимущество octopus merge перед двумя merge? Только количеством ревизий?
А вот второй аргумент меня зачастую весьма достаёт.
(к примеру команда pull в Git и Hg делает разные вещи).
Ага. Поэтому AuPull делает «hg pull --update», «svn update», «bzr pull» и до сих пор проваливается на некоторых реальных репозиториях git, так как я не знаю, как это правильно починить — ещё один пункт, из‐за которого я не люблю git.
Впрочем, pull/push (в основном только pull) — это единственные команды, которые доставляют мне проблемы при таком подходе, и то проблемы только с git — здесь он слишком не похож на остальных. log, commit, status, record, diff, annotate, hyperlink (:Gbrowse!), junk (remove/forget), track (add), name (tag/bookmark/branch), update, vimdiff, file (cat-file) проблем не доставляют абсолютно, а разница между VCS обычно не слишком значительна. Ещё есть grep, который имеет разное значение у mercurial и у всех остальных, но он не доставляет проблем, а только делает :AuGrep несколько несогласованной.
«git commit -a» не делает addremove. Но это не важно. «Неудобно» относится к тому, что возможность наличия чего‐то в staging area необходимо учитывать. Например, при добавлении нового файла в репозиторий с помощью «git add» «git diff» не покажет никаких изменений. Причина мне понятна, но необходимость помнить о ней неудобна.
Видео традиционно не работает (зато работает звук, что странно). Английскую речь без субтитров, как всегда, сложнее понять. Скачанный OGV в mplayer не работает также (QT работает). Ненавижу скринкасты, хотя этот неплох, если вы смогли его запустить.
Хотя кое‐что прояснилось: 1, 2, 3 есть (хотя и с замечаниями). 4 нету. Похоже, если есть staging area, то fugitive удобнее (4 не особо нужно) в этом отношении.
Если соблазнились, то сразу предупреждаю: дополнение предназначено в первую очередь для работы с mercurial. Всё остальное протестировано хуже. Кроме того, одним из основных предназначений дополнения является унификация работы в различных системах контроля версий. Т.е. в aurum вы работаете так, как будто staging area не существует, а все состояния файлов приводятся к 8 состояниям, используемым mercurial.
А можно конкретные команды? Пока это выглядит как AuRecord, но без окна с состоянием внизу. Окно же нужно:
Показывает состояние рабочей копии и какие файлы будут включены в изменение (первая колонка: не включён/включён частично/включён полностью/не включён, но редактировался для частичного включения)
Позволяет выбрать файлы для полного включения (в т.ч. неизвестные и удалённые, они будут добавлены или забыты). Причём выбрать скопом
Позволяет отменить изменения, предназначенные для частичного внесения или переоткрыть их заново
Хранит всю историю включений/изменений текущей сессии. То есть, делая undo/redo в окне состояния вы можете отменить или восстановить сделанные частичные изменения (правда гранулярность пока ниже: сохраняется только последнее состояние перед следующим изменением, произведённым в окне состояния; история правок внутри файла не сохраняется).
Можно узнать, как со всем этим справиться в fugitive?
Ага. Только меняться оно может. Mercurial просто не имеет возможности указать другому концу, что надо удалить некоторое изменение. С git вам достаточно изменить всё локально, удалить на том конце изменённые ссылки и сделать push. Больше старых измений никто не увидит, а первая же сборка мусора удалит их окончательно.
В Mercurial уже появились все необходимые средства для изменения локальной истории. Теперь появляется возможность спрятать изменения с помощью changeset obsolescence. Но удалить их по‐прежнему нельзя.
А как он решает задачу «Брать в commit лишь часть локальных изменений файла»? Насколько я знаю, AuRecord всё ещё не имеет аналогов. Fugitive, правда, позволяет писать в staging area, но я слабо представляю, насколько это удобно использовать для данной задачи.
Неудобно и ненужно. У меня просто vim открывает diff при фиксации изменений в соседнем окне и я делаю review. Никакая staging area никак не повлияет на возможность добавить скопом все изменения без review и тестирования, она только раздражает необходимостью писать на одну команду больше.
API официально нет, но на самом деле оно есть. На нём пишутся расширения, и оно на самом деле достаточно стабильно, чтобы его использовать. Просто не забывайте следить за изменениями и прогонять тесты после релиза.
А cli для hg — точно так же плохо, как для git. Те, кому надо написать интеграцию с mercurial просто забивают на совет его не использовать.
А теперь удалите ветку, не указав, откуда вы её хотите удалить. Я не про возможность не указать оба или последний из этих аргументов. Я про невозможность не указать только первый, указав второй.
Какой конфликт? У ветки может быть сколько угодно голов. Так всегда делают для feature branches если неохота придумывать имена для закладок или вообще неохота их использовать.
Не вижу разницы — что в одном случае учить один набор команд, что в другом — другой. Да ещё и git’овский rebase — почему нельзя было сделать так, чтобы что и куда указывалось ключами. «hg rebase --source rebased --destination new-base» куда как понятнее «git rebase new-base rebased-tip», причём что и куда здесь очевидно*, а в git — нет. Схемы с «git rebase --onto new-base rebased rebased-tip» — вообще жесть, мне приходится каждый раз перечитывать «git help», чтобы что‐то сделать.
* Во‐первых, понятные имена ключей. Во‐вторых, указывается, что перемещать, а не последнее из перемещающихся изменений. Для тех, кому проще git’овское поведение у mercurial есть «--base». У git же нет «--source».
Закладки — это полный аналог веток в git. Нет никаких проблем иметь долгоживущие закладки вместе с долгоживущими ветками или использовать только их. А вот если вам важно сохранять информацию о том, к какой ветке принадлежит изменение, то в git ничего для этого нет.
Ещё и dulwich. Я знаю и использую libgit2. Но стабильного релиза ещё нет (правда, обещали, что следующий релиз — 1.* и со стабильным API, но сроки неизвестны), а binding’и к python (pygit2) не обладают всеми возможностями даже libgit2, сама libgit2 не обладает всеми возможностями git.
Кроме того, это независимый проект. Если человек использует git, то консольный клиент у него окажется почти наверняка, а вот libgit2 — нет. А вот с mercurial и bazaar не так — если он есть, то почти наверняка установлен «нормально», т.е. доступен для импорта в python. К subversion тоже зачастую прилагается C‐шная библиотека (официальная!). К git не прилагается ничего.
Phases не запрещают стрелять себе в ногу. Они только усложняют нажатие на курок.
Первый аргумент мне совершенно непонятен — в чём преимущество octopus merge перед двумя merge? Только количеством ревизий?
А вот второй аргумент меня зачастую весьма достаёт.
Впрочем, pull/push (в основном только pull) — это единственные команды, которые доставляют мне проблемы при таком подходе, и то проблемы только с git — здесь он слишком не похож на остальных. log, commit, status, record, diff, annotate, hyperlink (:Gbrowse!), junk (remove/forget), track (add), name (tag/bookmark/branch), update, vimdiff, file (cat-file) проблем не доставляют абсолютно, а разница между VCS обычно не слишком значительна. Ещё есть grep, который имеет разное значение у mercurial и у всех остальных, но он не доставляет проблем, а только делает :AuGrep несколько несогласованной.
Хотя кое‐что прояснилось: 1, 2, 3 есть (хотя и с замечаниями). 4 нету. Похоже, если есть staging area, то fugitive удобнее (4 не особо нужно) в этом отношении.
Можно узнать, как со всем этим справиться в fugitive?
В Mercurial уже появились все необходимые средства для изменения локальной истории. Теперь появляется возможность спрятать изменения с помощью changeset obsolescence. Но удалить их по‐прежнему нельзя.
Вообще для всех остальных задач, по‐моему, достаточно нормально написанного дополнения к vim.
А cli для hg — точно так же плохо, как для git. Те, кому надо написать интеграцию с mercurial просто забивают на совет его не использовать.
* Во‐первых, понятные имена ключей. Во‐вторых, указывается, что перемещать, а не последнее из перемещающихся изменений. Для тех, кому проще git’овское поведение у mercurial есть «--base». У git же нет «--source».
Кроме того, это независимый проект. Если человек использует git, то консольный клиент у него окажется почти наверняка, а вот libgit2 — нет. А вот с mercurial и bazaar не так — если он есть, то почти наверняка установлен «нормально», т.е. доступен для импорта в python. К subversion тоже зачастую прилагается C‐шная библиотека (официальная!). К git не прилагается ничего.