Gitextensions: Диалог фиксации - выбранные строки этапа не работают

Созданный на 28 окт. 2011  ·  25Комментарии  ·  Источник: gitextensions/gitextensions

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

Относительно этого было бы более ясно, если бы была выделена вся строка, а не только ее часть.

Самый полезный комментарий

Это случилось со мной с 2.48 по следующему сценарию:
Tools->Settings->Git config->Line Endings: Not set
Установка конца строки на любой из параметров решила проблему. Похоже, что not set в представлении effective - это проблема конфигурации, и, на мой взгляд, она должна отображаться как таковая.

Все 25 Комментарий

ну для обычной операции копирования / вставки выбор всей строки не работает ...

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

Ну, подумай спокойно. В случае фиксации очень необычно копировать текст из файла diff. Я видел другие решения, где копируется вся строка, и это нормально. Я бы подумал о функции копирования как о хорошей функции в этом случае. Я знаю, что вы используете то же представление при разборе файла. Так что, возможно, здесь подойдет отдельный класс (делегат?), Который обрабатывает только функции документа фиксации.

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

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

Ну в 2.25 точно не работало, в 2.26 как-то вроде работает, но официального исправления для этого не было. У меня была фиксация, которую я не мог разделить из-за такого поведения, поэтому мне пришлось зафиксировать ее «как есть». Я говорю о поведении gitx, который на данный момент является одним из лучших пользовательских интерфейсов. это интуитивно понятно и понятно. Когда вы выбираете строку в разнице во время фиксации, выделяется вся строка, и с правой стороны появляется ровно одна кнопка «stage line (s)» в зависимости от того, выбрали ли вы одну или несколько строк. если вы щелкнете по нему, строки будут поставлены или, наоборот, неустановлены. хотелось бы увидеть нечто подобное в gitextensions.

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

«На данный момент: похоже, это сработает, если вы выберете именно все строки, которые хотите (убрать) этап, а не какой-либо персонаж более или менее. Так, может быть, мы сможем закрыть проблему и снова открыть, когда станут ясны более подробные сведения о том, что происходит?»

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

Как я уже сказал ранее: если у вас есть чехол, который вы можете воспроизвести, сохраните это состояние, чтобы другие (или вы) могли попытаться решить проблему !! Без воспроизводимого тестового примера это никогда не исправить!

Не знаю, лучше мне открывать новый выпуск или нет, но я начну с комментария. Я с радостью открою новый выпуск, если так будет лучше.

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

Ссылки # 636

Вчера у меня была такая же проблема (не меньше в проекте GitExtensions). Некоторые строки в файле можно было разместить, а другие - нет. Я постараюсь воспроизвести это сегодня вечером.

Я воспроизвожу эту ошибку для файла .sln в кодировке UTF8 с BOM. Проблема появляется только тогда, когда кодировка различий в поле со списком - UTF8. Когда я переключаюсь на кодировку по умолчанию, все работает правильно.

Я думаю, что основная проблема, потому что в спецификации меняются номера строк

Я только что наблюдал похожую проблему в Git Extensions v2.28. С файлом, созданным с использованием окончаний строк Unix, добавленным с помощью Git Extensions, я получил предупреждения о том, что окончания строк не будут изменены в моей рабочей области, но будут заменены окончаниями строк Windows, если я снова проверил файлы. После этого я внес в файл два изменения. Затем попытка обработать только второй блок завершается ошибкой, утверждая, что исправление повреждено. Похоже, постановка первого фрагмента работает нормально. У инструмента командной строки git нет проблем с постановкой только второго фрагмента, несмотря на окончания строк, поэтому, похоже, это ошибка в Git Extensions.

Удаление файла и выполнение «git checkout» для получения версии с правильными окончаниями строк устраняет проблему - теперь я могу использовать Git Extensions для изолирования второго фрагмента патча, не вызывая ошибок.

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

Проблема, по-видимому, связана либо с кодировкой файла, либо, возможно, с окончанием строки, как упомянуто выше. Это случилось со мной только сегодня в проекте С #, содержащем комментарий с немецкими символами (Latin1, windows-1251?), И в одной строке он изменил (по любой причине) кодировку файла. Файл был переформатирован VS2010. Начиная именно с этой строки, каждая следующая строка не может проходить через GE (2.40, но также и в более ранних версиях). Постановка в core-git работает нормально.

Я только что обновился до 2.40 с 2.31, и теперь эта функция кажется полностью сломанной. Кажется, я не могу разместить какие-либо строки в каких-либо файлах. Я пробовал использовать как файлы C ++ в кодировке ANSI, так и файлы C # в кодировке UTF-8, которые большую часть времени использовались для работы в версии 2.31 (используется для получения проблем с последней строкой файла).

«… патч не удался… патч не применяется…»

+1

a670f1501103fbe0d214ab76811a33353cab87af исправлена ​​ошибка, появившаяся в 2.40

fd96875589f22851a691fa1f0f989816a77458aa исправляет проблему спецификации

Большое спасибо Янушу. Я перестроил GitExtensions, заменил файлы в Program Files, и он отлично работает.

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

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

Если кто-то воспроизведет эту ошибку в 2.41 или более поздней версии, откройте ее повторно.

У меня сейчас эта проблема с 2.43. Я не могу «Сдвинуть выделенные строки» где-либо в любом файле, если установлен флажок «Игнорировать изменения пробелов». (К сожалению, когда он не установлен, во многих файлах, которые я должен зафиксировать, каждая строка в файле удаляется, а затем каждая строка добавляется снова. Я не уверен, почему; возможно, это может быть вещь табуляции против пробелов, но это будет быть своеобразным, поскольку один из этих файлов - это .csproj, который обычно не редактируется вручную и, следовательно, не должен подвергаться изменениям в настройках.)

Эта функция не работает с игнорируемыми пробелами. Это больше похоже на проблему EOL.

Это случилось со мной с 2.48 по следующему сценарию:
Tools->Settings->Git config->Line Endings: Not set
Установка конца строки на любой из параметров решила проблему. Похоже, что not set в представлении effective - это проблема конфигурации, и, на мой взгляд, она должна отображаться как таковая.

Конкретный вариант этого, но, как сообщалось ранее от grantbowering, возникает у меня, когда «Игнорировать изменения начальных и конечных пробелов» или «Игнорировать все изменения пробелов» включены с GitExtensions 2.51.03, 64-разрядная версия Windows 10:

  1. Измените файл.
  2. Команды> Зафиксировать
  3. Наведите указатель мыши на окно сравнения диалогового окна фиксации.
  4. На появившейся верхней панели инструментов включите «Игнорировать изменения начальных и конечных пробелов» и / или «Игнорировать все изменения пробелов».
  5. Щелкните по измененной строке в разнице.
  6. Нажмите клавишу «S», чтобы обработать выбранную строку: error: patch failed: ... error: ... patch does not apply .

См. №3493.

Пт, 29 июня 2018 г., 20:03 per1234 [email protected] написал:

Конкретный вариант этого, но, как сообщалось ранее
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133, автор:
grantbowering возникает у меня, когда "Игнорировать начальные и конечные пробелы
изменения "или" Игнорировать все изменения пробелов "включен с GitExtensions
2.51.03, Windows 10 64 бит:

  1. Измените файл.
  2. Команды> Зафиксировать
  3. Наведите указатель мыши на окно сравнения диалогового окна фиксации.
  4. На появившейся верхней панели инструментов включите "Игнорировать интерлиньяж и
    завершающие изменения пробелов »и / или« Игнорировать все изменения пробелов ».
  5. Щелкните по измененной строке в разнице.
  6. Нажмите клавишу «S», чтобы обработать выбранную строку: error: patch failed:
    ... ошибка: ... патч не применяется.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги