Size: a a a

2021 September 06

A

Alex in ctodailychat
народ, как принято мерджить огромные рерайты в гите?

Вот есть бранч под названием "переписали все нахер". старый master можно выкидывать. Как быть?

я подозреваю, что git merge —strategy ours
но чтото меня останавливает
источник

AS

Alexey Shcherbak in ctodailychat
rebase + merge without conflicts :)
источник

A

Alex in ctodailychat
хм
источник

AS

Alexey Shcherbak in ctodailychat
а как много изменений ? диффа на сотни тысяч строк считает или все же не такой запредельно большой ПР ?
источник

AR

Anton Revyako in ctodailychat
вопрос в том, что это просто «выглядит не так» или проблемы с матчингом типов, например?
источник

VK

Vik Kuptsov in ctodailychat
имхо так же, как у вас принято мержить любой другой PR.
источник

AS

Alexey Shcherbak in ctodailychat
ну или если прям совсем все напрочь - хард ресет мастеру и git push origin master —force
источник

A

Alex in ctodailychat
ну не сотни тысяч конечно, но тысячи. т.е. задача - заменить мастер. "мерджить" не надо, код из мастера тупо не нужен

кстати, мы мастер и не трогали почти
источник

AS

Alexey Shcherbak in ctodailychat
ну тогда просто с правами перезаписи мастера говоришь - вот ваш новый мастер, пляшем теперь от него
источник

AM

Aga Mahmudov in ctodailychat
В форсом нельзя?)
источник

AS

Alexey Shcherbak in ctodailychat
Пока не очень понятно в чем сложность, мастер - такая же метка как и любая другая, если только у вас она не защищена (нельзя push —force) или туда уже успели другие накоммитить и теперь не хочется затереть их работу. В обоих случаях - делаешь rebase, правишь все merge conflicts, в интерактивном режиме (а лучше в гуях)  можно еще и коммиты по-squash-ить чтобы история была красивее, и тогда стандартный мерж PRа проходит без проблем.
источник

A

Alex in ctodailychat
да наверно так и сделаю... merge -s ours может потерять работу в мастере
источник

AS

Alexey Shcherbak in ctodailychat
мы так мержили и на 10к и на 30к строк в диффе. Для больших ПР если надо все же код ревьюить - можно сделать бранч-аккумулятор и фичи мержить туда по 1 (с squash commits) - ревьюить отдельно каждую фичу, в итоге в аккумуляторе может быть 10 фич, 10 больших коммитов но каждый отревьюен и все 10 можно смело влить в мастер
источник

AS

Alexey Shcherbak in ctodailychat
мне иногда так жалко одноклеточных ботов, они вот прям совсем на идиотов ловят...
источник

МС

Михаил Серебренников... in ctodailychat
Как говорится, проблема, которую можно решить деньгами, не проблема. Так и в SQLite вроде бы и есть проблемы, а вроде бы и есть стандартные их решения.
Вывод типа - запрашиваешь функцию с соответствием номера поля и типа.
Строковые идентификаторы таблиц, полей не проверяются компилятором, как в том же protobuf, но можно создать константу на каждый идентификатор и уже их использовать.
Строки в экзотических кодировках и бинарные данные если вставишь в запрос, то получишь проблем. Но можно вставить через аргументы, но при этом не забудь сосчитать правильное их количество, чтобы правильно составить запрос.
И т.д и т.п.
Вот есть JSON и Protobuf. Есть SQL и хотелось бы найти что-то аналогичное protobuf для БД. )
источник

AR

Anton Revyako in ctodailychat
у меня с типов начинался holistic.dev

на вход ddl (схему базы) + dml (сам запрос), а на выход получаешь типы ответа и возможные типы аргументов.

но оказалось, что это никому не нужно, потому что все пишут на orm
источник

МС

Михаил Серебренников... in ctodailychat
Не совсем. LINQ - это, грубо говоря, универсальный переводчик с одного языка на другой. Хотелось бы БД, которая бы предоставляла нативный язык запросов для того же С/C++.
источник

СА

Сергей Аксёнов... in ctodailychat
У MongoDB свой язык запросов, который представляет собой JSON-объект.
источник

МС

Михаил Серебренников... in ctodailychat
Holistic, судя по описанию, крутая штука. Спасибо. За наводку. Не то, что мне нужно, но полезно для других проектов.
источник

AS

Alexey Shcherbak in ctodailychat
т.е. еще dsl надо учить для того чтобы просто вытащить что-то ? выглядит как регресс, зачем DSL ?
источник