Каков самый простой способ зафиксировать и нажать один файл, оставив другие модификации в покое?
Я относительно новичок в Mercurial, и моя команда пробует его прямо сейчас в качестве замены Subversion.
как я могу зафиксировать и отправить один файл в другой репозиторий, оставив другие изменения в моем рабочем каталоге незафиксированными (или, по крайней мере, не перемещенными в другой репозиторий)?
это происходит для нас с миграцией базы данных. Мы хотим передать миграцию в систему управления версиями, чтобы администратор базы данных мог просматривать и редактировать ее во время работы над кодом изменения, чтобы идти вместе с этой миграцией базы данных. Изменения еще не готовы идти, поэтому мы не хотим, чтобы вытолкнуть все из них.
в subversion я бы просто сделал:
svn add my_migration.sql
# commit only the migration, but not the other files I'm working on
svn commit -m "migration notes" my_mygration.sql
и продолжайте работать локально.
это не работает с mercurial, так как когда я выталкиваю его в другой репозиторий, если в нем есть изменения, которые я не снял, он хочет, чтобы я вытащил их, объединил их и зафиксировал это слияние в репозитории. Совершает после слияние не позволяет вам пропускать файлы, поэтому оно заставляет вас фиксировать все в вашем локальном репозитории.
самое простое, что я могу понять, - это зафиксировать файл в моем локальном репозитории, клонировать мой локальный репозиторий, извлекать любые новые изменения из фактического репозитория, объединять их и фиксировать это слияние, и они выталкивают мои изменения.
hg add my_migration.sql
hg commit -m "migration notes" my_migration.sql
cd ..
hg clone project project-clone
cd project-clone
hg fetch http://hg/project
hg push http://hg/project
это работает, но мне кажется, что я упускаю что-то более простое, какой-то способ сказать mercurial игнорировать файлы, уже находящиеся в моем рабочий каталог, просто выполните слияние и отправьте файлы вместе. Я подозреваю, что ртутные очереди могут это сделать, но я еще не полностью Грок mq.
благодаря Джошу Мэтьюсу ниже, команда shelve-это именно то, что я ищу. Я не видел никаких отличных инструкций по установке с некоторыми googling, так что вот комбинированный материал, который я использовал, чтобы заставить его работать:
сделать это с:
hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve
единственный файл (в настоящее время) в проекте является hgshelve.py файл.
изменить ваш ~/.hgrc, чтобы добавить расширение полки, указывая на то, где вы клонировали РЕПО:
[extensions]
hgshelve=/Users/ted/Documents/workspace/hgshelve/hgshelve.py
тут вы можете hg shelve и hg unshelve для временного хранения происходят изменения. Это позволяет работать на уровне" патч ломоть", чтобы выбрать и выбрать элементы, чтобы отложить. Казалось, что он не отложил файл, указанный для добавления, только файлы, уже находящиеся в репо с изменениями.
6 ответов:
есть расширение Mercurial, которое реализует команды shelve и unshelve, которые дают вам интерактивный способ указать изменения для хранения до более позднего времени: Shelve.
прошло почти 2 года с тех пор, как я впервые задал этот вопрос. Я бы сделал это по-другому (как я уже упоминал в комментарии выше вопрос выше). То, что я бы сделал сейчас, было бы вместо этого зафиксировать мои изменения в одном файле в моем локальном РЕПО (вы можете использовать расширение записи hg только для фиксации фрагментов файла):
hg commit -m "commit message" filenameтогда просто вытолкнуть.
hg pushЕсли есть конфликт, потому что в РЕПО были внесены другие изменения, которые мне нужно сначала объединить, я бы обновление до родительской версии (см. " HG parents-r ."если вы не знаете, что это такое), зафиксируйте мои другие изменения там, чтобы у меня было 2 головы. Затем вернитесь к исходной фиксации одного файла и извлеките/объедините изменения в эту версию. Затем вытолкнуть изменения с
hg push --rev .чтобы вытолкнуть только один файл и слияние этой ревизии. Затем вы можете объединить две головы, которые у вас есть локально.
этот путь получает освобожданным вещества mq и потенциала для отклоненные куски и сохраняет все отслеживается системой управления версиями. Вы также можете "HG strip" ревизии прочь, если вы позже решите, что вы не хотите их.
tl; dr: мое первоначальное объяснение выглядит сложным, но я надеюсь, что оно полностью объясняет, как использовать очередь исправлений. Вот короткая версия:
$ hg qnew -m "migration notes" -f migration my_migration.sql $ hg qnew -f working-code # make some changes to your code $ hg qrefresh # update the patch with the changes you just made $ hg qfinish -a # turn all the applied patches into normal hg commits
Mercurial очереди делает такого рода вещи ветер, и это делает более сложные манипуляции наборов изменений возможно. Это стоит изучить.
в этой ситуации сначала вы, вероятно, захотите сохранить то, что находится в вашем текущем каталоге, прежде чем снимать изменения:
# create a patch called migration containing your migration $ hg qnew -m "migration notes" -f migration.patch my_migration.sql $ hg qseries -v # the current state of the patch queue, A means applied 0 A migration.patch $ hg qnew -f working-code.patch # put the rest of the code in a patch $ hg qseries -v 0 A migration.patch 1 A working-code.patchтеперь давайте сделаем некоторые дополнительные работы над рабочим кодом. Я собираюсь продолжать делать
qseriesпросто чтобы быть явным, но как только вы создадите ментальную модель очередей исправлений, вам не придется продолжать смотреть на список.$ hg qtop # show the patch we're currently editing working-code.patch $ ...hack, hack, hack... $ hg diff # show the changes that have not been incorporated into the patch blah, blah $ hg qrefresh # update the patch with the changes you just made $ hg qdiff # show the top patch's diffпоскольку вся ваша работа теперь сохраняется в очереди исправлений, вы можете отменить эти изменения и восстановить их после того, как вы вытащили удаленные изменения. Обычно, чтобы отменить все патчи, просто сделайте
hg qpop -a. Просто, чтобы показать эффект на очереди патчей, я вытащу их по одному время.$ hg qpop # unapply the top patch, U means unapplied $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qtop migration.patch $ hg qpop $ hg qseries -v 0 U migration.patch 1 U working-code.patchв этом месте, как будто нет никаких изменений в вашем каталоге. Сделайте
hg fetch. Теперь вы можете снова включить изменения очереди исправлений и объединить их, если есть какие-либо конфликты. Это концептуально несколько похоже на перебазирование git.$ hg qpush # put the first patch back on $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qfinish -a # turn all the applied patches into normal hg commits $ hg qseries -v 0 U working-code.patch $ hg out migration.patch commit info... blah, blah $ hg push # push out your changesна этом этапе вы вытеснили миграцию, сохраняя при этом другие локальные изменения. Другие изменения находятся в исправлении в очереди. Я делаю большую часть своего личного развития, используя очередь исправлений, чтобы помочь я лучше структурирую свои изменения. Если вы хотите избавиться от очереди исправлений и вернуться к нормальному стилю, вам придется экспортировать свои изменения и повторно импортировать их в "нормальный" mercurial.
$ hg qpush $ hg qseries -v 0 A working-code.patch $ hg export qtip > temp.diff $ rm -r .hg/patches # get rid of mq from the repository entirely $ hg import --no-commit temp.diff # apply the changes to the working directory $ rm temp.diff
Я очень зависим от очередей патчей для разработки и
mqявляется одним из самых красивых реализаций там. Возможность создавать несколько изменений одновременно действительно улучшает то, насколько сосредоточены и чисты ваши коммиты. Это займет некоторое время, чтобы привыкнуть, но он идет невероятно хорошо с рабочим процессом системах.
другой вариант, если вы не хотите полагаться на расширения, - это локальное сохранение клона вашего вышестоящего репозитория, который вы используете только для таких задач интеграции.
в вашем примере вы можете просто вытащить/объединить свое изменение в хранилище интеграции/восходящего потока и отправить его непосредственно на удаленный сервер.
то, что я использую, как правило, используется для совершения одним файлом :
hg commit -m "commit message" filenameв случае, если позже, у меня есть конфликт слияния, и я все еще не готов зафиксировать свои изменения,выполните следующие действия:
1) создайте файл патча.
hg diff > changes.patch2) отменить все ваши выдающиеся незафиксированные изменения, только после проверки вашего файла патч.
hg revert --all3) потяните, обновите и объедините до последней версии
hg pull -u hg merge hg commit -m "local merge"4) Теперь просто импортировать патч обратно и получить внесенные изменения.
hg import --no-commit changes.patchНе забудьте использовать флаг-no-commit от автоматической фиксации изменений.
так как вы сказали проще всего, я часто использую
hg commit -i(--interactive) даже при фиксации целых файлов. С--interactiveвы можете просто выбрать файл(Ы), который вы хотите, а не вводить их весь путь(ы) в командной строке. В качестве дополнительного бонуса вы можете даже выборочно включать / исключать куски в файлах.и только потом
hg pushчтобы нажать эту вновь созданную фиксацию.Я поставил более подробную информацию об использовании
hg commit --interactiveв этом ответе: https://stackoverflow.com/a/47931672/255961
Comments