Отмена коммита из-за пустого сообщения коммита.
У вас не возникнет этой проблемы с Git 2.17 (Q1 2018), так как "git rebase" научился использовать новую опцию: "--allow-empty-message".(это значение по умолчанию в Git 2.19, см. ниже)
См. commit a6c612b (04 февраля 2018) Genki Sky (``) .
(Объединено Junio C Hamano - gitster - in commit 2f6128d , 21 Feb 2018)
rebase: добавить --allow-empty-message параметр
Этот параметр позволяет перебрасывать коммиты с пустыми сообщениями о фиксации, совпадая с тем же параметром в git-commit и git-cherry-pick.
при пустом журналесообщения не одобряются, иногда их можно найти в более старых хранилищах (например, переведенных из другой VCS), или есть другие причины для их получения.
Параметр доступен в git-commit и git-cherry-pick, поэтому его естественно сделатьдругие инструменты git прекрасно с ними работают.
Добавление этого параметра в качестве опции позволяет по умолчанию «дать пользователю возможность исправить», не прерывая при этом рабочий процесс пользователя.
Элан Руусамяэ подтверждает в комментариях :
работает как шарм.построен с применением указанного коммита.+
git rebase --root HEAD --allow-empty-message
Successfully rebased and updated detached HEAD.
git checkout -B master
С Git 2.19 (Q3 2018), --allow-empty-message является опцией по умолчанию:
См. commit b00bf1c , commit 1634688 , commit 0661e49 , commit 4d34dff , commit 983f464 , commit c840e1a , commit 9929430 (27 июня 2018 г.) и коммит d4e8062 , коммит 5dacd4a (25 июня 2018 г.) Элайджа Ньюрен (newren) .
(Объединено с Junio C Hamano - gitster - в коммит 0ce5a69 , 24 июля 2018 г.)
git-rebase: make -allow-empty-message Бэкэнды перебазирования по умолчанию
в настоящее время ведут себя по-разному с пустыми сообщениями фиксации, в основном как побочный эффект различных базовых команд, на которых они основаны.основанные на am ребазы применяют коммиты с пустым сообщением о фиксации, не останавливая и не требуя от пользователя указывать дополнительный флаг.(Интересно отметить, что перебазирование на основе am является типом перебазирования по умолчанию, и никто никогда не запрашивал флаг --no-allow-empty-message, чтобы изменить это поведение.) Перебазирование на основе слияния и интерактивное основание (котороев конечном счете основаны на git-commit), в настоящее время останавливаются при любых таких коммитах и требуют от пользователя вручную указать, что делать с коммитом, и продолжить.
Одним из возможных объяснений различий в поведении являетсячто цель перебазирования на основе "am" состоит исключительно в том, чтобы трансплантировать существующую историю, в то время как "интерактивная" перебазировка - это та, цель которой состоит в том, чтобы отшлифовать серию перед тем, как сделать ее публикуемой.
Таким образом, остановка и запрос подтверждениядля возможной проблемы больше подходит в последнем случае.
Однако есть две проблемы с этим обоснованием:
- 1) ребаз основанные на слиянии также неинтерактивны, и существует несколько типов ребаз, которые используют интерактивный механизм, ноне является явно интерактивным (например, если указаны
--rebase-merges или --keep-empty без --interactive).
Эти ребази также используются исключительно для трансплантации существующей истории, и поэтому также должны по умолчанию --allow-empty-message. - 2) это обоснование говорит только о том, что пользователь более склонен к остановке в случае явно интерактивной перебазировки, но не то, что остановка по этой конкретной причине действительно имеет смысл.
Изучение того, имеет ли это смыслв смысле, требует резервного копирования и анализа базовых команд ...
Если git-commit по умолчанию не выдает ошибки при пустых коммитах, случайное создание коммитов с пустыми сообщениями будет очень распространенным явлением (этот чек поймал меня много раз).
Кроме того, почти все такие пустые сообщения о фиксации будут считаться случайной ошибкой (о чем свидетельствует огромное количество документации по системам контроля версий и в различных сообщениях в блогах, объясняющих, как важны сообщения о фиксации).
Простая проверка того, что в противном случаеТаким образом, общая ошибка имела большой смысл, и git-commit получил флаг --allow-empty-message для особых случаев переопределений.
Это делало коммиты с пустыми сообщениями очень редкими.
Существует два источника коммитов с пустыми сообщениями для rebase (и cherry-pick):
- (a) коммиты, созданные в git, где пользователь ранее указал
--allow-empty-message для git-commit и - (b) коммиты, импортированные в git из других систем контроля версий.
В случае (a) пользователь уже явно указал, что в этом коммите есть что-то особенное, что заставляет его не хотеть указывать сообщение фиксации;принуждение их к повторному уточнению с каждым выбором вишни или перебазировкой скорее приводит в бешенство, чем полезно.
В случае (b) крайне маловероятно, что коммит был написан лицом, импортировавшим историю и выполняющим ребаз или вишню, и, таким образом, пользователь вряд ли будет подходящим человекомнаписать для него сообщение о коммите.
Остановка и ожидание, что пользователь изменит коммит, прежде чем продолжить, таким образом, кажется контрпродуктивным.
Далее, обратите внимание, что пустые сообщения о фиксации были распространенной ошибкой для git-commit чтобы справиться с этим, это редкий случай для перебазирования (или выбора вишни).
Тот факт, что это редкость, поднимает вопрос о том, почему стоило бы проверить и остановиться на этом конкретном условии, а не на других.
Например, почему интерактивная перебазировка не останавливается автоматически, если первая строка сообщения фиксации имеет длину 2000 столбцов, или пропускает пустую строку после первой строки, или каждая строка имеет отступ с пятью пробелами, илилюбое количество других многочисленных проблем?
Наконец, обратите внимание, что если пользователь, выполняющий интерактивную перебазировку, обладает необходимыми знаниями для добавления сообщения для любого такого коммита и хочет это сделать, он довольно простоизмените соответствующую строку с 'pick' на 'reword'.
Тот факт, что тема пуста в списке задач, который редактирует пользователь, должен даже служить способом их уведомления.
Насколько я могу судить, тот факт, что основанные на слиянии и интерактивные ребазы останавливаются при фиксации с пустыми сообщениями о фиксации, является лишь побочным продуктом, основанным на git-commit.
Это произошло без уведомлениядавно именно потому, что такие случаи редки.Редкость этой ситуации мешала рассуждать, поэтому, когда люди в конце концов заметили это поведение, они решили, что оно имело место по уважительной причине, и просто добавили флаг --allow-empty-message.
По моему мнению, остановка на таких сообщенияхнежелательно ни в одном из этих случаев, даже в (явно) интерактивном случае.
Примечание: "git rebase" и т. д. в Git 2.19 не может прерваться, если дано пустое сообщение журнала фиксациив результате редактирования, которое было исправлено в Git 2.20 (Q4 2018).
sequencer: исправить поведение --allow-empty-message, сделать его умнее
В commitb00bf1c ("git-rebase: сделать --allow-empty-message значением по умолчанию", 2018-06-27, Git v2.19.0-rc0), было дано несколько аргументов для трансплантации пустых коммитов без остановки и запроса подтверждения для каждого пользователя.совершить.
Эти аргументы были неполными, поскольку логика явно предполагала, что единственными рассматриваемыми случаями были трансплантация коммитов с пустыми сообщениями (см. Комментарий о «Существует два источника коммитов с пустыми сообщениями).
Он не обсуждал и даже не рассматривал повторные слова, сквоши и т. Д., Когда у пользователя явно запрашивается новое сообщение о коммите и предоставляется пустое.
(Плохо, я должен был подумать об этом в то время, но просто не задумывался.)
Награды и сквоша существенно различаются, как описано SZEDER:
Let's suppose you start an interactive rebase, choose a commit to
squash, save the instruction sheet, rebase fires up your editor, and
then you notice that you mistakenly chose the wrong commit to
squash. What do you do, how do you abort?
Before [that commit] you could clear the commit message, exit the
editor, and then rebase would say "Aborting commit due to empty
commit message.", and you get to run 'git rebase --abort', and start
over.
But [since that commit, ...] saving the commit message as is would
let rebase continue and create a bunch of unnecessary objects, and
then you would have to use the reflog to return to the pre-rebase
state.
Также он заявляет:
Инструкции в шаблоне сообщения коммита, который показан для 'reword' и 'squash', также все еще говорят...
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
Это обоснованные аргументы о том, что при редактировании сообщений коммита во время операции секвенсора, если сообщение коммита пусто, операция должна быть остановлена и попросить пользователя исправить.Аргументы в коммите b00bf1c (на который ссылаются выше) по-прежнему применяются при пересадке ранее созданных коммитов с пустыми сообщениями коммита, поэтому секвенсор не должен останавливаться на них.
Более того, все обоснования до сих пор в равной степени применимы для cherry-pickперебазироваться.
Следовательно, сделайте код:
- по умолчанию
--allow-empty-message при пересадке существующего коммита и - по умолчанию остановка , когда пользователя просят отредактировать сообщение о коммите и предоставляет пустое - как для rebase, так и для cherry-pick.