Как объединить два и более коммитов в один?

Question

[Дмитрий]

Мне хочется найти самый простой способ для решения сабжа?

Хотелось бы упростить свою работу с Mercurial, а пока она выглядит так:
1) hg clone <repositary-url> my-work
2) Копирую my-work в my-work-public
3) произвожу все магические действия с кодом в папке my-work
4) Затем начинаю отсматривать комиты от первого после клонирования к последнему. Попутно когда делаю hg up <ревизия> я мержу папки my-work и my-work-public с помощью WinMerge
5) Затем делаю hg push из my-work-public

подробнее:
Когда я веду работу с кодом, то какие-то комиты ломают сборку, но они мне нужны чтобы не запутаться что же я делал вообще. Но перед отправкой в репозитарий нужно создать набор комитов, которые не ломают сборку, для этого я использую WinMerge. Откатываясь на нужную мне ревизию в my-work, я могу затем смержить папку и сделать очередной hg ci -m "" в my-work-public, но уже не ломающий.

Мне кажется этот процесс можно упростить, но читая доку «Глава 12. Управление изменениями с Mercurial Queues» думаю что это все-таки будет тоже излишне громоздко. Есть ли способ еще проще чем MQ?

P.S.:
Возможно сумбурно написал, хоть и старался по-лучше, если что спрашивайте уточняющие :)

Comments

[Дмитрий]

То что я спрашиваю в Git решается через интерактивное rebase. Мне нужно это же но для Mercurial, при этом не просто какие-то комиты принять, а какие-то нет но и во время принятия указать новый тип сообщения

[Дмитрий]

Кажется есть кое что ) RebaseExtension. Теперь возникает вопрос: А какие еще есть способы работы? Мы же программеры знаем, что, как правило, задачу можно решить разными способами и не редко их больше двух!

Answer 1

[gribozavr]

mercurial.selenic.com/wiki/MqExtension

Можете коммитить как обычно, затем преобразовать всё в патчи, объединить/разрезать как нравится, преобразовать обратно в коммиты и запушить.

Comments

[Дмитрий]

Т.е. по сути вы не почитали мой вопрос )))
А в моем вопросе было:
>>Есть ли способ еще проще чем MQ?
Это уже говорит о том что я знаю о существовании MQ. Пока думаю остановиться на нем, но его загрязнение истории мне тоже не нравится.

[Дмитрий]

+ мне не нравится тем что преобразование в патчи можно только одного комита: hg qimport <нужный комит>.
Мне бы хотелось бы несколько комитов подряд идущих в один патч.
Я пробовал применить hg qrefresh последовательно переключая комиты и обновляя и что-то у меня не получился комулятивный патч. Возможно что-то не то делал, поэтому изучаю еще, я только вчера начал играться с этим расширением

[gribozavr]

> Это уже говорит о том что я знаю о существовании MQ.

Да, пропустил.

> преобразование в патчи можно только одного комита

hg qimport -r X:Y

[Дмитрий]

А коммулятивный только последовательным применением hg qfold все верно?

[gribozavr]

Насколько я знаю, да: stackoverflow.com/a/3762551/2221718

[Дмитрий]

Спасибо! Очередной вопрос по MQ, надеюсь последний ;)

возьмем такую ситуацию:

d:\projects\RemoveFwStreams>hg log -l 5
changeset:   661:159b10fa0942
//...
changeset:   660:650679a45e6a
//...
changeset:   659:84c113bb926e

хочется объединить в один патч два комита, делаю:

d:\projects\RemoveFwStreams>hg qimport -r 659:660
abort: revision 660 has unmanaged children

Все таки объединить несколько комитов нельзя. Просто не совсем понял про «unmanaged children», пока надеюсь на просветление от гугла )

[gribozavr]

Нужно импортировать и 661 тоже. Если бы можно было бы просто объединить 659:660 не трогая 661, то хеш 661 стал бы неправильным.

[Дмитрий]

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

Возможно это будет при работе с патчами через MQ может через RebaseExstension пока не решил

[gribozavr]

Когда хотите что-либо запушить в основной репозиторий, можете просмотреть hg outgoing, заимпортировать всё это в MQ (если пушили куда-то не в основной репозиторий, то вам просто так заимпортировать не удастся и нужно будет сменить фазу через hg phase), отредактировать патчи как нравится, преобразовать в коммиты и запушить в основной репозиторий.

[Дмитрий]

Спасибо! Думаю мой вопрос исчерпан, закрою. Остановлюсь на MQ.

[Дмитрий]

Возник еще один вопрос. Надеюсь еще не надоел ;)

Ситуация такая:
0) Создаем форк проекта
1) Делаем клон репозитария от форкнутого нами проекта
2) Проделали работу, за комитили множество вещей
3) С помощью манипуляций hg qimport -r X:Y; hg qfold; hg qfinish причесали патчи и превратили их в комиты
4) Делаем hg push в наш за форкунутый проект
5) Делаем pull request

спустя время, один из участников просмотрев наши комиты увидел что есть бага, которая появляетя 5 из 15 наших комитов.
Как теперь поправить комит, если правка бага одна строчка в нем?

Обобщая вопрос: Какие есть средства правки существующих комитов заявленных в pull request-е?

[gribozavr]

Снова MQ и редактирование истории. При этом инстумент ревью скорее всего вас не поймёт и комментарии могут потеряться.

Или ещё один коммит сверху. Чудес нет.

[Дмитрий]

Ну если верить статье Зачем пользователи GIT-а редактируют свои коммиты, то в Git подобное возможно с помощью rebase. Разве в Mercurial этого нельзя достичь?

Answer 2

[chersanya]

Несмотря на то, что прошло достаточно много времени, всё-таки напишу несколько строк о более удобном решении, чем MQ (по мнению, в том числе, самих разработчиков mercurial).

А именно, расширение histedit (которое уже давно поставляется вместе с Mercurial, а значит тестируется так же и имеет согласованный интерфейс). Оно представляет удобный способ свёртки, изменения, редактирования, удаления, перемещения коммитов в истории, причём всё достаточно интуитивно для пользователя.

Так же есть менее известное и пока не распространяемое вместе с Mercurial, (не из-за отсутствия стабильности, а в основном из-за некоторой несогласованности интерфейса, опций, поведения) расширение evolve (так же changeset evolution, mercurial.selenic.com/wiki/ChangesetEvolution), которое пишет один из разработчиков. Оно во-первых изменяет поведение стандартных команд, которые редактируют историю, давая некоторые приятные фишки: а) возможность получить любую версию удалённого или изменённого коммита (да, это версионность самих версий файлов), и б) можно менять опубликованную историю, причём она коррекно изменится у всех людей склонировавших репозиторий (есть небольшие оговорки). Также это расширение добавляет некоторые дополнительные команды, например для свёртки нескольких коммитов — hg fold.

Оба этих расширения используются самой командой разработки Mercurial в официальных репозиториях.

Comments

[Дмитрий]

Не совсем понял Вашу мысль, буду сегодня расшифровывать ;)

[Дмитрий]

Я понял Вашу мысль, но MQ он значительно лучше!!! Зря не включается сразу (((

Answer 3

[pomeo]

Не знаю правильно ли я понял, на примере гита у него есть такая штука git commit -p, которая позволяет пройтись по всем изменениям за раз и какие-то принять, какие-то нет. Прямого аналога в mercurial нет, но есть похожее mercurial.selenic.com/wiki/RecordExtension

Comments

[Дмитрий]

Да, как уже сказали в гит это rebase, но как Вы верно увидели тема не про гит, а про меркуриал!

Answer 4

[Дмитрий Балобанов]

Вам надо работать с бранчами. Делаете какую-то фичу — создаете отдельную ветку.
А зачем вы делаете пункт 2?

Comments

[Дмитрий]

Нет. Бранчи тут не помогут. Бранчи это история сложных процессов. К примеру по созданию фичи, правки сложного бага и др. действий. Основное правило любой системы контроля версий это — ни один комит не имеет права ломать сборку!

А я же описываю свой текущий внутренний процесс, когда я комичу даже «ломающие» комиты.
К примеру я знаю что я сейчас пойду спать и понимаю, что если я оставлю все исходники в этом состоянии то утром возможно что-то не пойму и чтото сделаю не так. Тогда принимаю решение «сохраниться» т.е. сделать более менее логический шаг и закомитить. Примером такого логического шага может быть «удаление интерфейса, т.е. чистого базового класса у которого лишь чистые вирт.функции» и я это комичу. Придя утром по логу hg log я могу понять, что сейчас мне надо удалять потомки. Но это ломает сборку и код!

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

Про п.2:
Потому что в этом состоянии папки находятся в одинаковом состоянии после клонирования репозитарии.
Одна папка для того чтобы из нее потом сделать hg push она для публикации, а вторая для «черновой» работы. Вся работа ведется в черновой папке. Черновая папка может содержать, как правило содержит, «ломающие» сборку комиты. А после завершения работ как раз и начинаю перенесения работы из черновика в папку для публикации. Делаю я это откатом на каждый комит, его просмотром, возможно откачусь на след. комит(ы) в черновой папке и сведения до такого состояния чтобы полученные изменения привели к комиту не ломающему сборку и после этого применяя WinMerge между двумя папками черновой и для публикации делаю hg ci -m уже в папке для публикации.
Сейчас понятней? )

[Никита Гусаков]

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

[Дмитрий]

Я описывал ситуацию с удалением. Как бы Вы поступили в этой ситуации? Т.е. прям сейчас Вас клонит спать\зовет жена погулять с ребенком\шеф обсудить индексацию зарплаты\друг у него что-то не комиллируется.

Опишу задачу еще раз: Вам прямо сейчас нужно оторваться, а процесс не завершено что вы сделаете в случае когда нужно удалить интерфейс, т.е. базовый класс с чистыми виртуальными методами?

Мои предположения что вы можете сделать:
* Записать на обычный бумажный листочек(у меня вечно со стола что-то пропадает, то жена порядок наведет, то уборщица на работе);
* Просто взять и удалить и оставить папку в том состоянии что есть. Надеясь на то что когда придете сразу же поймете что Вы в прошлый раз делали(У меня память не такая, постоянно забываю);
* Записать в todo-комментарий или прям в todo-менеджер(вечно забываю поглядеть в todo, никак в привычку не переводу это занятие).

[rvller]

ну сделали вы изменение, которое ломает сборку, но вы же об этом знаете. если вы закоммитите его в вашу ветку (на которой никто кроме вас билд собирать не будет) и на следующий день прочитав комментарий к последнему коммиту вы поймёте что делать дальше. на то она и ваша development-ветка, чтобы трекать изменения. И по-моему основное правило адекватных систем контроля версий (не ClearCase например) — это не «ни один комит не имеет права ломать сборку», а «один коммит — одно изменение», этакая атомарность коммитов.
Опять таки, папки копировать тоже не обязательно. Сделай две ветки. Одну для «грязного девелопмента», а вторую для стабильных, законченных изменений.

[Дмитрий]

>>Одну для «грязного девелопмента», а вторую для стабильных, законченных изменений.
Публикация «грязных» комитов на паблик не просто не рекомендуется, за это надо сразу руки отрывать!

>> это не «ни один комит не имеет права ломать сборку», а «один коммит — одно изменение», этакая атомарность коммитов.
И вот тут ты Вы правы, Но не добавили что этот комит обязательно должен быть рабочим, в любом случае!

От работоспособности комита зависит дальнейшее использование. К примеру как Вы представляете себе работоспособность команды hg bitsect при комитах ломающих сборку?

[rvller]

что значит «в паблик»? если это ваша локальная ветка для разработки, то это ничего не испортит. в конце концов вы можете тэг добавлять что на данном коммите билд не собирается, но это опять-таки только для себя. и как выше заметил OnYourLips не обязательно на ВСЕХ ветках и ВСЕХ коммитах в них билд должен собираться.

[Дмитрий]

>>что значит «в паблик»?
Вы не внимательно читали сам вопрос. О том что такое для меня я указал в посте своего вопроса! «в паблик» для меня это папка из которой в последствии применяется команда 'hg push'. Об этом п.5. Для тех кто этого не понял, еще раз пояснил см. мои комментарии. В виду того что все комиты в этой папке попадают в репозитарий куда я «проталкиваю» их и они становятся видимыми другим участникам имеющим к этому репозитарию куда протолкнул.

>>не обязательно на ВСЕХ ветках и ВСЕХ коммитах в них билд должен собираться.
Если эти ветки доступны участникам проекта, то абсолютно любой комит обязан быть «рабочим», т.е. не ломать сборку! К примеру в open-source проекта за этим строго следят мантейнеры. Очень хорошо помню свой первый комит на github-е, да, он ломал сборку только в одном комите. Но даже за него мне высказали «man git», а ведь могли объяснить где находится озерно Нахой в латинской америке и это было бы справедливо.

[Дмитрий]

OnYourLips
>>Есть мнение, что это распространяется только на мастер, но не на бранчи
Нет. На любой бранч! Не важно какой он главный или по правке бага или еще для какой работы. Все эксперименты ведутся на компах участников проекта и только. В репозитарии должно быть исключительно работающее решение. Любой бранч это не только история, но и возможный инструмент отладки. К примеру с помощью bisect можно вычислить где появилась бага. Это даст любому разработчику в проекте возможность быстро получить среду по отладке кода. Что будет если кто-то залил ломающий сборку код? Это приведет к тому что разработчик перед правкой бага должен сначала пофиксить сборку и только потом уже заняться делом. Для чего ему спрашивается терять время если кто-то залил не работающий код?