Как выполнить построчно в git gui, хотя в конце предупреждения файла нет новой строки

Я использую git gui для выбора строк для подготовки к фиксации. Обычно это работает как шарм. Мне известно о возможности сделать то же самое в командной строке.

Если файл изначально не имеет новой строки в конце файла, git gui распознает это и добавляет предупреждающее сообщение в редактор, как я проиллюстрировал на снимке экрана.

Git Gui

Проблема

Проблема, возникающая из-за отсутствия разрыва строки, заключается в том, что человек больше не может обрабатывать и фиксировать отдельные строки. Когда я щелкаю правой кнопкой мыши, чтобы выбрать конкретную строку, и выбираю Stage line for commit из контекстного меню, появляется сообщение об ошибке.

ошибка: фатальный: поврежден parch в строке 11.

Проблема не является специфической для операционной системы и может быть воспроизведена в Windows, MacOSX и Linux. Я знаю, что могу избежать проблемы, если добавлю новую строку в файл и зафиксирую эту версию, прежде чем продолжу выбирать отдельные строки.

Шаги по воспроизведению проблемы

  1. Инициализировать новый репозиторий.
  2. Создайте файл с тремя строками содержимого, каждая со словом «Hallo». Не ставьте новую строку в конце файла.
  3. Добавьте и зафиксируйте файл.
  4. Отредактируйте тот же файл, поместив слова между тремя строками.
  5. Откройте git gui и попробуйте внести изменения построчно.

Запрос

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

Сообщение об ошибке

Я отправил отчет об ошибке в список рассылки Git. Вы можете следить за обсуждением и участвовать в нем здесь.


git git-gui newline git-index line-by-line
person JJD    schedule 04.11.2012    source источник
comment
Это действительно отчет об ошибке для git-gui. Эта проблема должна возникать только для последнего фрагмента файла. Что происходит, когда вы ставите строки, git-gui создает патч, а затем применяет его с помощью git apply. В этом случае нам нужно удалить последнюю строку и снова добавить ее с новой строкой и оставить \ Нет новой строки в конце маркера файла в качестве контекста. Все это происходит в lib / diff.tcl apply_range_or_line. Это нетривиально, но это поправимо.   -  person patthoyts    schedule 06.11.2012
comment
Я согласен: было бы неплохо, если бы это можно было исправить в git gui. Хотя я не знаю, борются ли другие инструменты пользовательского интерфейса с теми же проблемами.   -  person JJD    schedule 06.11.2012

Ответы (2)


arrow_upward
5
arrow_downward

Благодаря Heiko Voigt в поведении исправлена ​​ошибка. Мы исправили это на конференции Git-Merge - спасибо GitHub за организацию. В настоящий момент патч находится в списке рассылки. Как только он будет объединен и выпущен, я собираюсь обновить этот пост здесь.

Наконец, gitgui-0.18.0 был объединен с git v1.8.4 и является частью официального выпуска (23 августа 2013 г.). Теперь каждый может наслаждаться построчными коммитами независимо от новой строки в конце файла. Еще раз спасибо Хейко!

person JJD    schedule 10.05.2013
comment
@Ikraav Я думаю, что вы первый человек, которого я заметил, который действительно обеспокоен этой ошибкой. Тем не менее, я с нетерпением жду выпуска исправления. - person JJD; 23.05.2013
comment
В настоящее время мы делаем немного (по общему признанию чрезмерно) централизованную работу с git, запускаем git gui удаленно, чтобы различные пользователи могли выполнять свою работу. Этот баг уже давно нас раздражает под зад. Сегодня был хороший день, это все, что я могу сказать по этому поводу :) - person lkraav; 24.05.2013
comment
@Ikraav Я рад, что сделал твой день приятным :) - person JJD; 24.05.2013

arrow_upward
3
arrow_downward

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

исходный сценарий был опубликован Мэттом Бейкером . Я свел это к факту добавления новой строки, но также включил процедуры для удаления завершающих пробелов. Однако есть одно изменение, касающееся символа переноса строки: я добавил \n вопреки рекомендации Мэтта.

Проблемный случай:

Я использовал сценарий в рабочем процессе git rebase. Это заставило git изменить все файлы с конечными пробелами. Это привело к огромной разнице. Поэтому рекомендую продумать использование скрипта.

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

person JJD    schedule 06.11.2012