А в чём монструозность? Обычный случай — есть ветка фичи с N коммитами. При ребейзе в некоторых коммитах возникли конфликты, последовательно их разрулил и всё.
Один раз исправил все конфликты, один раз проверил работоспособность, один раз с этим разобрался.
Не понимаю, в чём принципиальное различие — исправить N конфликтов в одном коммите мержа или те же N конфликтов в нескольких коммитах при ребейзе. Количество работы то же самое, но в случае ребейза решаешь конфликты только одного коммита за раз, что лично я нахожу весьма удобным, т.к. делается это в порядке хронологии, небольшими порциями и у каждой порции есть конкретный контекст. В случае большого количества изменений это порой единственный способ не запутаться при мерже.
В итоге есть две ветки, в каждой из которых можно пошагово проверить наличие той или иной проблемы. Или же определить, что проблема появилась именно в момент слияния.
В случае ребейза слияние будет распределено по коммитам, т.е. проверять нужно будет на один шаг меньше. А в случае проблем сразу понятно, при слиянии чего именно что-то пошло не так.
Однако, такой подход мне кажется лишённым смысла, он не только не даёт никакой пользы, а скорее разрушает историю, уничтожает истинный ход событий.
Истинный ход событий в общей истории никому не интересен, как и избыточные коммиты вроде «fix bug». Это только усложняет поиск нужной точки в истории при необходимости. По-хорошему бранч перед мержем надо причесать, всякие «fix bug» накатить fixup'ами на соответствующие коммиты. Т.е. да, править локальную историю, но в этом и философия — никому не надо в деталях знать как это разрабатывалось (и сколько кофе вы при этом выпили), интересует только максимально презентабельный результат в общей истории.
При мерже конфликты разрешаются один раз, так как комит один. А ребэйз — считай, по черри-пику на каждый коммит исходной ветки на новый корень.
Но общее число конфликтов от этого ведь не меняется. Да, возможно придётся править те же самые файлы, но я вижу в этом только плюс — если коммиты делать не хаотично, а отражать ими атомарные изменения, то и пошагово разрешать конфликты куда удобней, меньше вероятность запутаться и допустить ошибку.
Хотя и тут есть исключения, ведь rebase с конфликтами — та еще боль и иногда проще создать лишний merge-коммит, вместо того, чтобы тратить время на разрешение кучи конфликтов.
Слышал разные страшилки по поводу rebase и конфликтов, но на практике ни с чем подобным ни разу не столкнулся. Можете пояснить, в чём принципиальное отличие в разрешении конфликтов при merge и при rebase? Ведь конфликты в любом случае надо разрешать, и merge сам за вас это не сделает.
По моему, в IDE удобно только логи и диффы смотреть. Для всего остального набрать команду намного проще, чем искать какую-то кнопку и пытаться угадать как реально производимое действие легло на фантазии разработчика GUI.
Если вы постоянно работаете с конкретной IDE, запомнить пару хоткеев и использовать их гораздо эффективней набора команд.
Да ладно, люди порой такую работу проделывают, чтобы слямзить побольше. Эти бы амбиции да в благое русло, но там таких денег они не заработают. Так что если рассуждать не основываясь на имеющих эмоциональный окрас суждениях а-ля «что такое хорошо, что такое плохо», то частенько воровство вполне себе работа. Грязная, но работа.
Да и смысл отстреливать парашюты и включать посадочные двигатели, если ты уже «в планете»?
Конечный автомат же. Если условие выполнено, переходим к следующему состоянию. Вот, видимо, и получилось, что за короткий промежуток времени и парашют сбросил, и двигателями пореветь успел, и аппаратуру для работы на поверхности включил.
Вы же вроде в своём корпоративном блоге пишете, можете в нём рекламировать что угодно в рамках тематики сайта. Тем более, пост в корпоративном блоге уже сам по себе реклама.
Так что, я думаю, многим было бы интересно всё-таки узнать модель устройства.
Посмотрите на существующие реализации (например, CodeBlocks). В самой простой реализации это банальный редактор конфигураций, где можно задать команды сборки проекта/отдельного файла, пути, общие настройки (типа DEFINES и т.п.) и состав проекта или маски включения. Всё остальное уже вторично.
ОК, допустим, у вас проект, который не на CMake и мигрировать на него вы не собираетесь. Однако, вам не хватает удобной кроссплатформенной IDE и тут вы встречаете CLion. Что проще — продублировать всё в CMakeLists.txt или вбить пару команд сборки в настройках?
Не могу понять, какое это имеет отношение к моему комментарию. Я как раз предложил избежать этой проблемы и не использовать какое-либо конкретное решение в качестве единственно возможного варианта. Ну, или не ограничиваться набором конкретных поддерживаемых решений.
Почему бы не дать возможность создавать любой проект со свободной конфигурацией, командами сборки и т.п.? Это дало бы возможность вообще не зависеть от системы сборки. А CMake и т.п. вполне себе можно поддерживать дополнительно.
Всю информацию о том, какие файлы входят в проект, какой стандарт C++ стоит использовать, какие библиотеки и флаги компиляции будут использоваться, и т. д. CLion берет именно из CMake.
Это с самого начала вызывало у меня недоумение. CMake, независимо от того, насколько он популярен — не краеугольный камень, а всё-таки частный случай. Почему нет возможности создать freestyle-проект, который можно самостоятельно наполнить и настроить? Взять тот же CodeBlocks — он универсален, а ваша IDE — нет. Я так долго её ждал, а в итоге банально не смог ею воспользоваться, поскольку не использую CMake в качестве системы сборки.
Покупал Wii U в начале года. Лично моё мнение таково, что выпускать её стоило именно сейчас, потому что консоль не умирает, она была мертва с рождения, и только сейчас её реанимируют.
Серьёзно, я нигде не видел таких отвратных сервисов, такого бестолкового саппорта, настолько бажных и медленных прошивок и приложений (не считая Samsung Smart TV разве что) и такой беды с играми, как в случае Wii U (в моих глазах Nintendo Land чуть ли не единолично спасала ситуацию).
Частично они исправились, в остальном же остаётся ждать и надеяться, благо есть перспективы. Но всё равно поддерживаю идею, что ребёнку стоит купить именно Wii U (если речь не о подростке, там уж больше от нравов зависит). Nintendo Land уже достаточное для того основание.
Не понимаю, в чём принципиальное различие — исправить N конфликтов в одном коммите мержа или те же N конфликтов в нескольких коммитах при ребейзе. Количество работы то же самое, но в случае ребейза решаешь конфликты только одного коммита за раз, что лично я нахожу весьма удобным, т.к. делается это в порядке хронологии, небольшими порциями и у каждой порции есть конкретный контекст. В случае большого количества изменений это порой единственный способ не запутаться при мерже.
В случае ребейза слияние будет распределено по коммитам, т.е. проверять нужно будет на один шаг меньше. А в случае проблем сразу понятно, при слиянии чего именно что-то пошло не так.
Истинный ход событий в общей истории никому не интересен, как и избыточные коммиты вроде «fix bug». Это только усложняет поиск нужной точки в истории при необходимости. По-хорошему бранч перед мержем надо причесать, всякие «fix bug» накатить fixup'ами на соответствующие коммиты. Т.е. да, править локальную историю, но в этом и философия — никому не надо в деталях знать как это разрабатывалось (и сколько кофе вы при этом выпили), интересует только максимально презентабельный результат в общей истории.
Так что, я думаю, многим было бы интересно всё-таки узнать модель устройства.
Почему бы не дать возможность создавать любой проект со свободной конфигурацией, командами сборки и т.п.? Это дало бы возможность вообще не зависеть от системы сборки. А CMake и т.п. вполне себе можно поддерживать дополнительно.
Жаба задушила...UPD: Видать цена обновиться не успела, теперь 75%.
Серьёзно, я нигде не видел таких отвратных сервисов, такого бестолкового саппорта, настолько бажных и медленных прошивок и приложений (не считая Samsung Smart TV разве что) и такой беды с играми, как в случае Wii U (в моих глазах Nintendo Land чуть ли не единолично спасала ситуацию).
Частично они исправились, в остальном же остаётся ждать и надеяться, благо есть перспективы. Но всё равно поддерживаю идею, что ребёнку стоит купить именно Wii U (если речь не о подростке, там уж больше от нравов зависит). Nintendo Land уже достаточное для того основание.