git rebase -i --retain-empty-commits

По умолчанию, когда вы используете git rebase -i, он комментирует пустые коммиты, и мне приходится их раскомментировать (они мне помогают). Есть ли вариант команды rebase, который предотвратит это нежелательное предположение, что я не хочу их сохранять?


person Sridhar Sarnobat    schedule 12.05.2016    source источник
comment
Построчно нет, погуглил да. Я ничего не мог найти.   -  person larsks    schedule 12.05.2016
comment
Моя ошибка, спасибо, что направили меня.   -  person Sridhar Sarnobat    schedule 12.05.2016


Ответы (2)


Хорошо, это было проще, чем ожидалось:

git rebase -i --keep-empty

Надеюсь, этот пост ускорит поиск ответа другими пользователями Google.

person Sridhar Sarnobat    schedule 12.05.2016

В Git 2.26 (1 квартал 2020 г.) «git rebase» научился использовать бэкэнд слияния (то есть механизм, который управляет «rebase -i») по умолчанию, в то же время разрешая параметру «--apply» использовать бэкенд «apply» (например, моральный эквивалент "format-patch piped to am").
(Переменную конфигурации rebase.backend можно задать для настройки.)

В рамках этого улучшения --keep-empty теперь используется по умолчанию!

Подписано: Элайджа Ньюрен

Вы прочитали документацию по git-rebase?

Различные бэкэнды перебазирования по-разному обрабатывают коммиты, которые начинаются пустыми (т. е. не имеют изменений относительно своего родителя), и в какой-то момент была добавлена ​​опция --keep-empty, позволяющая настроить поведение.
Обработка коммитов, которые начинаются пустыми, на самом деле очень похожи. на commit b00bf1c9a8dd ("git-rebase: сделать --allow-empty-message значением по умолчанию" , 27 июня 2018 г., Git v2.19.0-rc0 -- слияние указано в пакет № 4), в котором указывалось, что поведение различных бэкендов часто является случайным. чем дизайн.

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

В «git commit» имеет смысл выдавать ошибку при создании пустых коммитов, если только не указан флаг переопределения.

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

Конечно, пустые коммиты довольно редки, поэтому их обработке не уделяется много внимания, и люди склонны полагаться на существующее (случайное) поведение и предполагают, что для этого была причина, что приводит к тому, что они просто добавляют флаги (--keep-empty в этом case), которые позволяют им переопределить неверные значения по умолчанию.

Исправьте интерактивную серверную часть, чтобы --keep-empty было значением по умолчанию, так же, как мы сделали с --allow-empty-message.

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

Обратите внимание, что в t3421 был один тест, который, по-видимому, был написан, ожидая, что --keep-empty не будет правильным поведением по умолчанию.

Этот тест был представлен в commit 00b8be5a4d38 ("добавить тесты для перебазирования пустых коммитов", 06 июня 2013 г., Git v1.8.4-rc0 -- слияние), которое была частью серии, посвященной топологии перебазирования, и имела ссылку интересное оригинальное сопроводительное письмо, в котором отмечено

Ваш вклад особенно ценен в том, согласны ли вы с целью тестовых случаев.

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

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

rebase (interactive-backend): сделать --keep-empty значением по умолчанию

person VonC    schedule 04.03.2020