Mercurial говорит: "abort: выдающиеся незафиксированные изменения", я не хочу совершать

сценарий: локальное РЕПО, прежде чем я выйду из офиса

$ hg status

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

Я хочу, чтобы commit и push важно/обновление 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

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

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

30
commit mercurial push

5 ответов

использовать расширение чердаке временно отложить / сохранить незавершенное производство.

7

Если вы не хотите использовать shelve, вы можете сделать это всего с 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
34

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

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

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

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

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

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

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

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

5

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

[extensions]
tortoisehg.util.hgshelve =

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

$ hg shelve

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

5

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

определенная программа (например,печь FogCreek SW) предоставьте эту возможность, но даже если вы просто храните репозитории на сетевом / общем диске, вы должны быть возможность создания личного РЕПО есть.

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

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

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

1