git revert
выглядит частично разумно в этой ситуации. "Частично" потому что при наличии в ветке вендора изменений отсутствующих в стабильной ветке они не будут отменены. Они могут зависеть от отменённых изменений и могут не работать без них. Более правильным выглядит откат к конкретному коммиту в ветке вендора, с отменой всех изменений -- как взятых из стабильной ветки так и внесённых вендором. Но можно-ли вернуться, к примеру, на v4.14.289?
git cherry-pick v4.14.290..v4.14.291 ; git tag v4.19.291-my
, тогда возврат к конкретной версии -- это например git checkout vX.YY.ZZZ-my
или git rese --hard vX.YY.ZZZ-my
или git revert vX.YY.ZZZ-my..HEAD
, по обстоятельствам.git grep
или git log
. fetch только загружает информацию об изменениях, но не накатывает на локальную ветку
я хочу отменить коммиты из удалëнного репо, а не из локального
предлагаете мне отлаживать gcc?
Вопрос собственно в том - что такого вызывает gcc при оптимизации, чего я не пересобрал?
Возможно у нас просто разные критерии для "рядовых" разработчиков.
дефолтная задача для рядового разраба пишущего под винду
дефолтная…для рядового
Ровно в том, что я написал -- сначала флаги, потом cs:ip. cs:ip ровно в том же виде как это делает far call, т.е. сначала cs, потом ip.
Посмотреть на стек, конкретно в [ss:sp] -- ip, [ss:sp + 2] -- cs и [ss:sp + 4] -- flags.