Ситуация такая:
0) Создаем форк проекта
1) Делаем клон репозитария от форкнутого нами проекта
2) Проделали работу, за комитили множество вещей
3) С помощью манипуляций hg qimport -r X:Y; hg qfold; hg qfinish причесали патчи и превратили их в комиты
4) Делаем hg push в наш за форкунутый проект
5) Делаем pull request
спустя время, один из участников просмотрев наши комиты увидел что есть бага, которая появляетя 5 из 15 наших комитов.
Как теперь поправить комит, если правка бага одна строчка в нем?
Обобщая вопрос: Какие есть средства правки существующих комитов заявленных в pull request-е?
Мне хочется научиться следующему: во время работы в рабочей папке не париться о том что какой-либо комит может сломать сборку. Сломал и ладно, а когда завершил работу, то пересмотреть всю работу и какие-либо комиты которые ломают сборку объединить в один.
Возможно это будет при работе с патчами через MQ может через RebaseExstension пока не решил
+ мне не нравится тем что преобразование в патчи можно только одного комита: hg qimport <нужный комит>.
Мне бы хотелось бы несколько комитов подряд идущих в один патч.
Я пробовал применить hg qrefresh последовательно переключая комиты и обновляя и что-то у меня не получился комулятивный патч. Возможно что-то не то делал, поэтому изучаю еще, я только вчера начал играться с этим расширением
Т.е. по сути вы не почитали мой вопрос )))
А в моем вопросе было:
>>Есть ли способ еще проще чем MQ?
Это уже говорит о том что я знаю о существовании MQ. Пока думаю остановиться на нем, но его загрязнение истории мне тоже не нравится.
OnYourLips
>>Есть мнение, что это распространяется только на мастер, но не на бранчи
Нет. На любой бранч! Не важно какой он главный или по правке бага или еще для какой работы. Все эксперименты ведутся на компах участников проекта и только. В репозитарии должно быть исключительно работающее решение. Любой бранч это не только история, но и возможный инструмент отладки. К примеру с помощью bisect можно вычислить где появилась бага. Это даст любому разработчику в проекте возможность быстро получить среду по отладке кода. Что будет если кто-то залил ломающий сборку код? Это приведет к тому что разработчик перед правкой бага должен сначала пофиксить сборку и только потом уже заняться делом. Для чего ему спрашивается терять время если кто-то залил не работающий код?
>>что значит «в паблик»?
Вы не внимательно читали сам вопрос. О том что такое для меня я указал в посте своего вопроса! «в паблик» для меня это папка из которой в последствии применяется команда 'hg push'. Об этом п.5. Для тех кто этого не понял, еще раз пояснил см. мои комментарии. В виду того что все комиты в этой папке попадают в репозитарий куда я «проталкиваю» их и они становятся видимыми другим участникам имеющим к этому репозитарию куда протолкнул.
>>не обязательно на ВСЕХ ветках и ВСЕХ коммитах в них билд должен собираться.
Если эти ветки доступны участникам проекта, то абсолютно любой комит обязан быть «рабочим», т.е. не ломать сборку! К примеру в open-source проекта за этим строго следят мантейнеры. Очень хорошо помню свой первый комит на github-е, да, он ломал сборку только в одном комите. Но даже за него мне высказали «man git», а ведь могли объяснить где находится озерно Нахой в латинской америке и это было бы справедливо.
>>Одну для «грязного девелопмента», а вторую для стабильных, законченных изменений.
Публикация «грязных» комитов на паблик не просто не рекомендуется, за это надо сразу руки отрывать!
>> это не «ни один комит не имеет права ломать сборку», а «один коммит — одно изменение», этакая атомарность коммитов.
И вот тут ты Вы правы, Но не добавили что этот комит обязательно должен быть рабочим, в любом случае!
От работоспособности комита зависит дальнейшее использование. К примеру как Вы представляете себе работоспособность команды hg bitsect при комитах ломающих сборку?
Я описывал ситуацию с удалением. Как бы Вы поступили в этой ситуации? Т.е. прям сейчас Вас клонит спать\зовет жена погулять с ребенком\шеф обсудить индексацию зарплаты\друг у него что-то не комиллируется.
Опишу задачу еще раз: Вам прямо сейчас нужно оторваться, а процесс не завершено что вы сделаете в случае когда нужно удалить интерфейс, т.е. базовый класс с чистыми виртуальными методами?
Мои предположения что вы можете сделать:
* Записать на обычный бумажный листочек(у меня вечно со стола что-то пропадает, то жена порядок наведет, то уборщица на работе);
* Просто взять и удалить и оставить папку в том состоянии что есть. Надеясь на то что когда придете сразу же поймете что Вы в прошлый раз делали(У меня память не такая, постоянно забываю);
* Записать в todo-комментарий или прям в todo-менеджер(вечно забываю поглядеть в todo, никак в привычку не переводу это занятие).
Нет. Бранчи тут не помогут. Бранчи это история сложных процессов. К примеру по созданию фичи, правки сложного бага и др. действий. Основное правило любой системы контроля версий это — ни один комит не имеет права ломать сборку!
А я же описываю свой текущий внутренний процесс, когда я комичу даже «ломающие» комиты.
К примеру я знаю что я сейчас пойду спать и понимаю, что если я оставлю все исходники в этом состоянии то утром возможно что-то не пойму и чтото сделаю не так. Тогда принимаю решение «сохраниться» т.е. сделать более менее логический шаг и закомитить. Примером такого логического шага может быть «удаление интерфейса, т.е. чистого базового класса у которого лишь чистые вирт.функции» и я это комичу. Придя утром по логу hg log я могу понять, что сейчас мне надо удалять потомки. Но это ломает сборку и код!
Это похоже на работу методов класса, внутри любого метода инварианты могут нарушаться, но вот за пределами работы метода объект обязан быть в рабочем состоянии и не важно что произошло, толи брошено исключение, толи завершена работа метода, толи еще что-то.
Про п.2:
Потому что в этом состоянии папки находятся в одинаковом состоянии после клонирования репозитарии.
Одна папка для того чтобы из нее потом сделать hg push она для публикации, а вторая для «черновой» работы. Вся работа ведется в черновой папке. Черновая папка может содержать, как правило содержит, «ломающие» сборку комиты. А после завершения работ как раз и начинаю перенесения работы из черновика в папку для публикации. Делаю я это откатом на каждый комит, его просмотром, возможно откачусь на след. комит(ы) в черновой папке и сведения до такого состояния чтобы полученные изменения привели к комиту не ломающему сборку и после этого применяя WinMerge между двумя папками черновой и для публикации делаю hg ci -m уже в папке для публикации.
Сейчас понятней? )
Кажется есть кое что ) RebaseExtension. Теперь возникает вопрос: А какие еще есть способы работы? Мы же программеры знаем, что, как правило, задачу можно решить разными способами и не редко их больше двух!
То что я спрашиваю в Git решается через интерактивное rebase. Мне нужно это же но для Mercurial, при этом не просто какие-то комиты принять, а какие-то нет но и во время принятия указать новый тип сообщения
Ок, это значительно лучше чем я пользуюсь прямо сейчас ) Но как настроить поиск по избранному, чтобы сразу из браузера искать, не ходя по всяким гугл-адвансед?
Сейчас перепроверил след. поведение. Если нажать на метке, которую уже была поставлена автором до добавления в избранное. Затем если по этой метке щелкнуть, то будет выведено не только эта статья, но и те что не в избранном. А мне нужно работать именно с избранным
Напишите user-story как Вы их используете? Потому что у меня как-то с ними не получается подружиться ) Метки всего лишь сужают поиск и кол-во выводимой информации на экран, но все равно не настолько чтобы было удобно пользоваться
