Mercurial говорит «прервать: невыполненные невыполненные изменения», я не хочу совершать - PullRequest
30 голосов
/ 15 января 2011

Сценарий: локальное репо, прежде чем я покину офис

$ hg status

M important/update1
M another/important/update2
M work/in/progress

Я хочу зафиксировать и нажать важное / обновление1 и важное / обновление2 , потому что я хочу вытащить эти файлы в локальное хранилище, когда вернусь домой. Я не готов совершить работа / в / прогресс . На самом деле это даже не правильно разобрать. Этот файл открыт в моей IDE, и я просто хочу оставить его как есть.

Теперь я делаю: (поспешно, трамвай уходит через три минуты)

$ hg commit important/update1 another/important/update2
$ hg push

pushing to https://**censored**
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)

Ok. Коллега что-то толкнула ... (трамвай уходит через две минуты ...)

$ hg pull (really important update!)
$ hg update

abort: outstanding uncommitted changes

Дерьмо. Мне нужно обновление коллег, но я не собираюсь совершать work / in / progress , а тем более подталкивать его! И я просто пропустил свой трамвай ...

Как вы справляетесь с этим?

Ответы [ 5 ]

35 голосов
/ 01 мая 2012

Если вы не хотите использовать полку, вы можете сделать это всего за 3 команды:

hg diff > mylocalchanges.txt

hg revert -a

# Do your merge here, once you are done, import back your local mods

hg import --no-commit mylocalchanges.txt
7 голосов
/ 15 января 2011

Используйте мансардное расширение для временного хранения / сохранения незавершенного производства.

6 голосов
/ 18 января 2011

Рабочий процесс для людей, разрабатывающих несколько функций / исправлений ошибок одновременно:

Одна из возможностей - клонировать столько хранилищ, сколько функций вы разрабатываете. Но это может быть дорого в дисковом пространстве, времени, а также сбивает с толку. Другая возможность состоит в том, чтобы работать над другой темой в одном и том же локальном репозитории (назовем его Main), но использовать только второй для выборочной фиксации одной или нескольких требуемых функций в центральном репозитории.

Это очень хорошо объяснено и подробно описано в этой статье:

https://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly

Если вы когда-либо встречаете следующие сообщения об ошибках:

  • «abort: push создает новые удаленные головки!» (Потенциальные множественные головки)
  • «abort: пересекает ветви (используйте« hg merge »или« hg update -C »)» (рабочий каталог в ветви, отличной от извлеченных изменений), или
  • «abort: невыполненные незафиксированные изменения» (невозможно объединить из-за локальных изменений)

затем в статье выше объясняется, почему все это происходит, и предлагается рабочий процесс, позволяющий избежать этих проблем. Примечание: также можно использовать механизм исправлений mqueues для продвижения ваших изменений (см. Комментарий №1 статьи).

Надеюсь, это поможет.

5 голосов
/ 15 января 2011

Я обычно использую расширение полки TortoiseHg , которое вы также можете активировать для использования на своей cmdline:

[extensions]
tortoisehg.util.hgshelve =

Теперь вы можете использовать команды:

$ hg shelve

Если вы знаете, что обновление не будет мешать нашей работе, вы также можете принудительно установить / обновить (hg pull -f).

1 голос
/ 18 января 2011

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

Некоторые программы (например, FogCreek's Kiln SW ) предоставляют эту возможность, но даже если вы просто храните репо на сетевом / общем диске, вы сможете создать там личное репо.

Если это не так (то есть: у вас нет прав доступа к серверу), вы также можете рассмотреть возможность использования именованной ветви. В этом случае вы просто фиксируете свою именованную ветку и отправляете эту ветку на сервер. Предположительно, ваш коллега оставил бы ваши названные ветви в покое, и не было бы ничего нового, что можно было бы объединить. В терминах «беспорядка веток», да, они присутствуют на протяжении всего срока действия репозитория, но закрытие названной ветви перед слиянием удалит их из виду и решит некоторые проблемы.

> hg update <branch name>
> hg commit --close-branch -m 'closing branch <branch name>'

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

...