как толкать кучу изменений, как один в Mercurial

Question

Как я понимаю, одно из главных преимуществ распределенной системы контроля версий, такой как Mercurial, заключается в том, что вам не нужно беспокоиться о том, чтобы что-то сломать в своем супер-важном основном репо (которое используется довольно многими другими разработчиками), и делать все, что вы работа и исследования в вашем личном удаленном клоне, пока вы не поймете, что все стабильно, и вы можете отодвинуть свою работу назад. И, следовательно, у меня возник вопрос: можно ли отодвинуть не всю историю изменений (с несколькими изменениями, которые вы сделали для себя), а только ту, которая фактически отличается между вашим репо и текущим состоянием мастера.

Один пример:

hg init master-repo; cd master-repo  
echo -e 'Important file\nWith Bug!' > file  
hg commit -A -m "initial commit"  
cd ..; hg clone master-repo hotfix-repo; cd hotfix-repo  
echo "fix1" >> file  
hg commit -m "first attempt to fix bug"  
echo "fix2" >> file  
hg commit -m 'Fixed it!'

Теперь (возможно, после извлечения и слияния с последними изменениями master-repo) я хочу отодвинуть только один набор изменений, содержащий все изменения, которые я сделал без моей локальной истории изменений. Одно из возможных решений - создать еще один клон, а затем использовать diff / patch между двумя клонами, чтобы извлечь / применить изменения из первого и зафиксировать их все сразу во втором репо. Затем сделайте толчок, как в обычном случае. Но возможно ли так, используя только ртутные команды?

Спасибо вперед!

Answer 1

Мнения расходятся в отношении того, стоит ли объединять наборы проб и ошибок в один набор изменений перед нажатием:

• Плюсы: вы избегаете наборов изменений в своей истории, когда ваш набор тестов дает сбой - эти наборы изменений плохи для hg bisect и добавляют шум.

• Con: вы не можете свернуть наборы изменений, которые вы опубликовали в других репозиториях - при этом будут перезаписываться только ваши локальные наборы изменений, и тогда вам придется очищать другие репозитории вручную.

Технически, совершенно безопасно объединить набор изменений в один набор изменений перед нажатием. Вы начинаете с

... a --- b --- c --- x --- y --- z

и вы переписываете это в

... a --- b --- c --- w

, где w имеет точно такое же состояние репозитория, что и z (но, очевидно, другой родительский набор изменений). Здесь нет слияний (и, следовательно, нет конфликтов слияний), поэтому оно не может потерпеть неудачу.

После переписывания вы можете тянуть и объединить с вышестоящими (d и e):

... a --- b --- c --- w --- v
                 \         /
                  d ----- e

Вам нужно расширение, чтобы переписывать историю любого рода. Здесь я бы предложил один из:

• Свернуть расширение : как видно из названия, это расширение предназначено для свертывания наборов изменений.

• Расширение Histedit : полноценное редактирование истории, но команда сгиба позволяет свернуть наборы изменений.

• Расширение базы данных : это стандартное расширение может перемещать наборы изменений вокруг и одновременно сворачивать их. В приведенном выше примере он будет перемещаться x --- y --- z после e:

  ... a --- b --- c --- d --- e --- x' --- y' --- z'
  

  Затем можно при желании свернуть x' до z':

  ... a --- b --- c --- d --- e --- w'
  

  По сравнению с простым свертыванием x в z, перебазирование включает в себя слияния, поэтому может произойти сбой.

Answer 2

Введение

Я думаю, что переписать историю и отправить / получить "отполированные" наборы изменений (в стиле Git-Boys), как правило, плохая идея - история - это история, она имеет свою ценность.

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

Краткий ответ

Нет. В Mercurial вы тянете / толкаете и получаете и принимаете полный набор наборов изменений, что создало разницу в истории репо

Длинный ответ

Каким-то образом вы можете, перемотав свою историю изменений перед обменом на «другую сторону». Просто запомните - каждый набор изменений представляет не новое состояние объекта, а diff между старым и текущим (если опишете его в ближайшее время), таким образом - обычным удалением изменений вы можете получить неправильный конечный результат.

В любом случае, у вас есть много способов переписать собственную историю (в виде расширений):

• Collapse
• История редактирования
• MQ (с mq-patches как таковыми, сворачиванием наборов изменений в mq-patch и разделением таким же образом)
• Может быть, некоторые другие, неизвестные мне