Нужно изменить один коммит в истории. Что вы сделаете?

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

Вариант «не заниматься ерундой» не рассматривается?

Допустим, история еще нигде не опубликована.

Создам бранч tmp с коммитами до нужного, не включая его, потом применю к данной ветке оставшиеся коммиты через git rebase -i.

git rebase -i $commit_to_edit^, помечаем его как edit, запускаем rebase, редактируем, git rebase --continue.

Задача ведь не исключить коммит, а изменить.

1. Но только если эти коммиты еще не улетели на сервер, потому что будет merge и проблемы. Но проще не мучиться и сделать еще один коммит.

Годно.

А в чем проблема при интерактивном вызове rebase напротив нужного коммита заменить pick на edit?

Только в том, что я не знал про edit. Или забыл.

Сабж и создавался с целью чтобы невозможно было вносить правки задним числом.

5. Ничего не делать — история должна быть неприкосновенной.

Бочку варенья этому господину.

Если проект общественный, то просто сделаю новый коммит, исправляющий предыдущий.

Если проект собственный, то просто rebase -i -root.

git-овцы такие git-овцы

Rebase + reword

Абсолютно не согласен. История коммитов служит конкретной практической цели — логически группировать изменения. Это позволяет иметь осмысленненную семантику операций bisect, annotate и revert. Неприкосновенность (между релизами) никому не нужна, она не даёт практических преимуществ.

Это как давать определение, не имеющее никаких полезных свойств (на которых можно было бы построить теорию).

<вброс>а я сегодня делал git push -f на гитхаб</вброс>

Сабж и создавался с целью чтобы невозможно было вносить правки задним числом.

ты с svn не перепутал? :)

Сабж и создавался с целью чтобы невозможно было вносить правки задним числом.

ты с svn не перепутал? :)

Не перепутал.

Пользователи svn смеются над вашими проблемами :)

давай, расскажи мне, как делать в svn правки задним числом :)

Для подобных целей esr пилит reposurgeon.

истерически?

лол, тред прикидывающихся шлангами

Если в не master branch, то разрешаю.

[fat-mode]Git by design разрешает легко отстрелить ногу ломать историю, в mercurial подобную акцию вандализма сделать сложнее.[/fat-mode]

Нужно изменить один коммит в истории

Яхвыч, я тебе с самого начала говорил, что твоя идея насчёт социалистической революции в России - это полное говно. Теперь ничего уже не переиграешь.

наоборот, это гит такое позволяет. а анонимус написал что сабж (гит) создавался чтобы «невозможно было вносить правки задним числом.» это 4.2, т.к. гит чуть более чем полностью состоит из средств правки истории.

Если в не master branch, то разрешаю.

пока вроде не приходилось, но может я просто забыл.

Нужно

Не нужно же, ну!

истерически?

Исторически. )

история должна быть неприкосновенной.

http://ria.ru/society/20140410/1003291154.html

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

Вот, Вова всё правильно говорит, а вы — переписать, переписать. Учиться надо, на ошибках-то!

наоборот, это гит такое позволяет. а анонимус написал что сабж (гит) создавался чтобы «невозможно было вносить правки задним числом.» это 4.2, т.к. гит чуть более чем полностью состоит из средств правки истории.

Анонимус прав, git позволяет только сделать альтернативную историю правкой в прошлом, а не менять конкретную. От этой особенности есть ключик -f у push

История коммитов служит конкретной практической цели — логически группировать изменения.

Тут должна быть ссылка твои репы с подобной историей, гг.

ок, я не так понял. не задумывался о правке истории в этом контексте.

Создай новый бранч с коммита, стоящего перед требующим исправление. Измени по-новому и сделай коммит. Затем последовательно сделай cherry-pick оставшихся коммитов из оригинальной ветки. Если понадобится удали все коммиты из основного бранча и сделай merge из нового.

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

https://github.com/intelfx/data-processing, например. Есть проект побольше, но его я не могу показать, ибо NDA и прочее дерьмище.

1. git rebase -i, перемещение нужного коммита в голову, редактирование, git commit --amend, git-rebase -i обратно на прежнее место.

Упрлс? Никакого перемещения никуда не нужно, коммит можно редактировать прямо на месте. Это и есть единственный нормальный способ.

нет! если коммит вносит баг, нужно срочно затереть этот коммит!

И плачут когда смотрят лог.

git позволяет только сделать альтернативную историю правкой в прошлом, а не менять конкретную

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

бедняги.. как же тяжело вам с плюсами живётся то..

Для логической группировки изменений есть коммиты. А история служит другой цели — возможности найти момент конкретного изменения, чтобы понять, как оно было сделано, или вернуться к нему. Что невозможно, если ты куски этой истории поменял или повырезал уже пост фактум.

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

полет твой полет мысли никого не интересует

Интересует, когда 50 коммитов спустя находят кусок кода и начинают разбираться, зачем он там, с какой целью засунут и баг он или фича.

нет, не интересует. интересует только результат, т.е. компиляция полёта твоих мыслей в единый минимальный логический блок, описанный intelfx подход решает эту проблему на порядки лучше.

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

Это называется «коммит». А теперь расскажи, зачем его править или удалять.

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

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

если не поймёшь - то перечитай 2 раза - если не поймёшь снова - то обращайся.

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

Меня интересует, зачем этот логически завершённый коммит править или удалять.