Как Ъ откатить часть толстого проекта?

Проблема не простая, советовать можно только пальцем в воздух. Но я бы сделал хард ресет на известный коммит, сделал реверт этого коммита и потом черри пик последующих коммитов вручную.

то, что ты собрался откатывать, сложено в одном каталоге каком-то или разбросано по проекту? или тебе вообще часть одного файла откатить хочется?

Тебе нужно откатить один коммит, или несколько подряд, или несколько вразнобой?

Разбросано конечно. Но некоторые файлы придется откатывать частями.

на самом деле все еще хуже - речь идет о двух взаимодействующих проектах;-) Ну видимо их придется как то параллельно причесывать…

Коммит на котором все условно работало отстает на два десятка коммитов от текущего состояния. Меня бы наверное устроило слияние того коммита с текущим состоянием, но это неточно.

Непонятно че вообще делать с системой сборки. Видимо только методом тыка…

то, что «часть файла» - импоссибле, только руками.

если список файлов имеется, скорми его по очереди команде git checkout <goodCommit> -- ${pathToFile} например, сложив нужные пути в файл и потом cat requiredPaths.txt | xargs -n1 -I{} git checkout <goodCommit> -- {}

Пока что я пытаюсь понять как получить общий список файлов измененных с конкретного коммита;-)

git diff --name-only спасет отца русской демократии

Во, спасибо большое! Я че то в git log это пытался найти… ;-(

Я бы наверное сделал git reset --hard <good-commit> && git reset <latest-commit> (откат рабочего каталога на старое состояние), а потом с помощью tig и редактора возвращал новые изменения, проверяя работоспособность сборки и наличие бага. Но здесь пригодится некоторый навык и умение пользоваться tig, лучше тренироваться на копии репозитория.

Коммит на котором все работало бол-мен известен.

Может git blame покажет, какой коммит всё сломал, тогда его можно откатить либо же исправить.

Для меня это уже высший пилотаж;-(

В итоге я достал из рабочего коммита CMakeLists.txt и ключевой .i файл для swig-а а потом запустил cmake/make и начал тупо чинить руками то что отвалилось. Оказалось на удивление просто, после некоторых танцов с бубном оно собралось и даже какие то тесты работают.

ya-betmen, aol - спасибо за помощь!

Конечно там какие то хвосты остались висеть, но это уже надеюсь другие люди решать будут;-)

Надо бы конечно с гитом разобраться получше…

Сделай бэкап да поэкспериментируй :) Пока жива хотя б одна копия гитовой репы в оригинальном состоянии — все относительно безопасно и восстановимо :)

Вот поэтому надо мигрировать с git на darcs, ну или pijul

(Это не поможет разобраться с уже существующей проблемой)

Если пилите код за деньги то рекомендую прекратить гадить в одну кучу и начать заводить фичеветки. И хуками или надстройкой типа гитлаба можно сделать так чтобы в мастер нельзя было коммитить напрямую а мерж проходил только если все тесты зелененькие (ну или хотя бы проект билдится).

Я не буду рассказывать про то как делается академический софт - это грустная тема.

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

Я хочу верить что git это последняя система контроля версий с которой мне придется в жизни разбираться. Жизнь на самом деле короткая, и в ней есть куча куда более интересных вещей чем осванивание новых инструментов.

и в ней есть куча куда более интересных вещей

Список в студию.

академический софт

Так бы сразу и сказал

Это все очень субъективно. Скажем физика мне нравится больше чем изучение пятой по счету системы контроля версий.

Но, как мне кажется, у тебя нет выбора между физикой и пятой по счёту (из трех реально существующих, из которых две уже в формалине) системы контроля версий.

У тебя выбор между изучением системы контроля версий и

я достал из рабочего коммита CMakeLists.txt и ключевой .i файл для swig-а
потом запустил cmake/make
начал тупо чинить руками то что отвалилось.
после некоторых танцов с бубном оно собралось
какие то тесты работают.
Конечно там какие то хвосты остались висеть
это уже надеюсь другие люди решать будут;-)

Не то, чтобы я осуждал. В конце концов, это все очень субъективно.

Если есть короткий текст где описано все это счастье (настройка тестов, хуков и пр), желательно что бы оно прозрачно конфигалось одной командой - было бы интересно.

Но вес равно в итоге упрется в систему тестов. В одном из проектов у нас молодежь прикрутила гугл-тесты - мне скорее не понравилось. Много букв, и концепция «все есть тест» (где много букв) мешает жить. Кабы то же самое, но полаконичней…

И все равно, построить стройную систему тестов для числодробилки, где как правило тестирование функциональное, а тесты сложные и крупные - это надо сильно думать. Если такую систему удается построить по этому поводу обычно пишется большая статья, но это довольно редко бывает.

У тебя выбор между изучением системы контроля версий и …

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

Но, как мне кажется, у тебя нет выбора между физикой и пятой по счёту (из трех реально существующих, из которых две уже в формалине) системы контроля версий.

Вам кажется.

Если есть короткий текст где описано все это счастье (настройка тестов, хуков и пр), желательно что бы оно прозрачно конфигалось одной командой - было бы интересно.

Тут к сожалению не помогу. Я как-то уже примерно знаю что мне нужно и в случае необходимости просто догугливаю забытые места.

С другойстороны если вас там немного то вы можете просто устно договориться не ломать мастер. И бить того кто договоренность нарушает.

Дык он же не со зла… Он и не знал что сломал что то. Разные версии всяких утилит + разные ОС + куча функционала + цейтнот. Я не удивлюсь если у него вообще все работало.

Что бы такого не было нужны не просто тесты - эти тесты нужно гонять на разных платформах потому что проект кроссплатформенный. Ну и делает это все полтора инвалида - на выходе что есть то есть;-(

Если есть короткий текст где описано все это счастье (настройка тестов, хуков и пр), желательно что бы оно прозрачно конфигалось одной командой - было бы интересно.

Нет такого. Если кратко, для CI твой выбор заключается в том, продаться гитхабу или продаться гитлабу.

И все равно, построить стройную систему тестов для числодробилки, где как правило тестирование функциональное, а тесты сложные и крупные - это надо сильно думать. Если такую систему удается построить по этому поводу обычно пишется большая статья, но это довольно редко бывает.

Ой ладно… тесты начинают делать когда все по п#зде идет каждый день. Вот как у тебя, только непрерывно. И тогда всякие филосовские мысли сразу уходят. Припрет как следует - сразу разберешься :).

Если не приперло - ну и не парься.

продаться гитхабу или продаться гитлабу.

В таких проектах репа обычно на своем сервере за семью печатями.

Если не приперло - ну и не парься.

Это философия мне нравится, но хотелось бы таки эту границу «когда припрет» чуть отодвинуть от себя. Эпизодически возникают идиотские ошибки когда одно починил а другое поломал и потом начинаешь вытаращив глаза искать поломанное.

продаться гитхабу или продаться гитлабу. В таких проектах репа обычно на своем сервере за семью печатями.

Значит гитлабу, его вроде можно отдельно поднять на халяву. Есть еще github enterprize.

Вообще CI много, но я упомянул те, которые могут еще где-нибудь пригодиться.

Это философия мне нравится, но хотелось бы таки эту границу «когда припрет» чуть отодвинуть от себя. Эпизодически возникают идиотские ошибки когда одно починил а другое поломал и потом начинаешь вытаращив глаза искать поломанное.

Тебе стимул нужен :). Например, если в публичном проекте 1000 пользователей, и ты будешь регулярно обваливать мастер, то тебе забьют тикетами трекер, и ты будешь заниматься только им. Очень мотивирует на исправление процесса.

Пока это только твои хотелки, без явных стимулов - будешь заниматься филосовскими вопросами, вместо реальных :). До тех пор, пока не столкнешься со всем разнообразием трындецов, у тебя просто не будет опыта, где можно срезать углы, а где надо тесты сразу писать.

Из раздела lmgtfy, но выглядит работоспособно:

Для одного файла и одного коммита:

git show <sha1> -- <filename> | git apply -R

Дальше - нужно скриптянский писать. Возможно, в каком-то из гуёв есть шоткат на это действие, но я ими не пользуюсь.

Важно понимать чем это решение отличается от git checkout <sha1> - тут ты именно отменяешь изменения только из этого коммита только для этого файла, а не откатываешь файл на версию .

Коммит на котором все работало бол-мен известен.

Ну я начинаю с того, что проверяю этот коммит, потом половинным делением иду с того коммита на более свежий, проверяю его и далее делю ещё раз пополам.

Вот в этом смысле, кстати, svn был удобнее гита. Там номер ревизии - просто счётчик. И пополам можно делить в буквальном смысле разницу между номерами ревизий. А в гите хеши, по которым ещё проследи, когда чего.

Хочется пока что тупо откатить эту часть, но не потерять кучу правок сделанных в других частях.

Ну значит, надо сначала точно установить виноватый коммит и проанализировать, ЧТО ИМЕННО в нём менялось, и что из этого ответственно за багу. Вычленить криминальное место и попробовать как-то откатить только его в последней ревизии.

P.S. Упс, опоздал.

Вот в этом смысле, кстати, svn был удобнее гита. Там номер ревизии - просто счётчик. И пополам можно делить в буквальном смысле разницу между номерами ревизий. А в гите хеши, по которым ещё проследи, когда чего.

Зато в гите этот метод прямо вшили в бисект, насколько я понял. Правда я не пользовался.

P.S. Упс, опоздал.

Все равно спасибо;-)