Невозможно использовать git add с опцией --patch

Недавно я обновил Git до версии 2.7.2.windows.1 (у меня 64-разрядная версия Windows 7). После обновления мне не удалось запустить git add с параметром -p для файлов в определенном каталоге (или его подкаталогах), имя которого _ (знак подчеркивания).

git status правильно сообщает, что в моем файле есть изменения:

PS C:\Users\Carl\www\dl> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   _/php/class.Menu.php

И я могу добавить весь файл простым git add, или указав файл по имени. Но если я попытаюсь включить опцию -p или --patch (оба варианта дают одинаковые результаты), Git сообщит, что изменений нет:

PS C:\Users\Carl\www\dl> git add -p .\_\php\class.Menu.php
No changes.

Это происходит только для файлов в каталоге _, но не имеет значения, cd ли я вхожу в этот каталог, чтобы запустить команду git add без необходимости явно указывать путь со знаком подчеркивания; это все еще не работает:

PS C:\Users\Carl\www\dl\_\php> git add -p .\class.Menu.php
No changes.

Первоначально я думал, что эта проблема связана с аналогичной проблемой, с которой я недавно столкнулся в файлах в каталоге _, о котором я спрашивал здесь. Однако эта проблема, по-видимому, связана с преобразованием пути Posix в MinGW, тогда как эта проблема возникает независимо от того, использую ли я Git Bash, Windows PowerShell или cmd.exe.

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

Это ошибка в Git? Могу ли я предпринять какие-либо дополнительные шаги, чтобы определить основную проблему?


git windows filenames git-add
person Carl Fink    schedule 08.03.2016    source источник
comment
вы проверили коммит или ветку?   -  person Christian Grabowski    schedule 09.03.2016
comment
Нет, это не новый файл. Это файл, который уже существует в репозитории, в который я просто внес изменения.   -  person Carl Fink    schedule 09.03.2016
comment
Вы проверены на одном коммите, хотя? По моему опыту, это может привести к странному поведению, над которым нужно работать.   -  person Christian Grabowski    schedule 09.03.2016
comment
Нет. Я просто на обычной ветке, и все в курсе.   -  person Carl Fink    schedule 09.03.2016
comment
Тогда мне придется согласиться с ответом @Walle, это не очень хорошо, но это должно сработать.   -  person Christian Grabowski    schedule 09.03.2016
comment
не могли бы вы показать нам свой .gitignore?   -  person Sulthan    schedule 12.03.2016
comment
Когда вы запускаете его в bash, попробуйте вместо этого git add -p ./_/php/class.Menu.php. В bash \ — это escape-символ, а не разделитель каталогов. Дайте мне знать, если это поможет или нет, пожалуйста.   -  person jpmc26    schedule 12.03.2016
comment
Примечание для будущих читателей: этот вопрос обсуждался на Meta.   -  person halfer    schedule 13.03.2016

Ответы (2)


arrow_upward
14
arrow_downward

Ну, я смог воспроизвести это, и кажется, что это то же самое преобразование пути POSIX-to-Windows. ProcessMonitor показывает, что git (на самом деле perl запускается git) ищет файл C:\Program Files\Git\php\class.Menu.php.

Чтобы обойти это (по крайней мере, это сработало для меня), согласно documentation, вы можете временно установить переменную окружения MSYS_NO_PATHCONV, например так (в git bash):

MSYS_NO_PATHCONV=1 git add -p _/php/class.Menu.php

(Я не знаю, как установить переменные env в cmd/powershell Windows, но это тоже должно быть возможно.)

Не следует включать MSYS_NO_PATHCONV глобально/постоянно (например, используя export в git bash или изменяя пользовательские/системные переменные среды Windows в системных настройках), поскольку это может привести к нежелательным эффектам и, вероятно, сломать гораздо больше вещей, чем исправить (см. merge-conflic#comment53791560_32680723">этот ТАК комментарий). На самом деле, ребята из git-windows предупреждают даже о временных включение MSYS_NO_PATHCONV.
Сказав это, я начинаю думать, что проблема OP — это ошибка git for-windows, и о ней следует сообщать как таковую (возможно, это как-то связано с тем фактом, что git-add является двоичным , но git-add--interactive — это сценарий perl).

Другой указанный обходной путь — удвоить первую косую черту, например git add -p _//php/class.Menu.php (или это означает, что параметр должен начинаться с двойной косой черты?), но это, похоже, не работает из-за сложных преобразований промежуточных путей, которые происходят между вызовом git add и реальный доступ к файлам.

person Roman    schedule 11.03.2016
comment
Чтобы установить переменные env в cmd Windows: set MSYS_NO_PATHCONV=1 - person Stijn de Witt; 14.03.2016
comment
@StijndeWitt Или откройте Панель управления > Система > Дополнительные параметры системы > Переменные среды, особенно если вам нужно что-то установить для всех пользователей, а не только для текущего пользователя. - person GalacticCowboy; 14.03.2016
comment
@GalacticCowboy Просто помните, что изменения переменных среды в панели управления не отображаются где-либо еще до перезагрузки. - person Dan Is Fiddling By Firelight; 14.03.2016
comment
@DanNeely, обычно перезапуска конкретной программы достаточно, но перезагрузить может быть проще, чем запустить программу, которая использует несколько служб, которые необходимо перезапустить (и которые явно не связаны). - person Dan Field; 14.03.2016
comment
@DanField В случае git мы обычно говорим об окне консоли (cmd), а не о службе и т. д. Очень просто выйти и перезапустить ее. - person GalacticCowboy; 14.03.2016
comment
@DanField Я не помню, чтобы когда-либо добавлял/менял его без перезагрузки. Совсем недавно пытались использовать vagrant/etc для создания виртуальной машины rails и для написания нового установщика для старого приложения MFC. Первый был в окне консоли; перезапуск командной строки ничего не дал. В последнем случае приложение отказывалось признавать, что его среда var существует до перезагрузки. Необходимость протестировать установщик с несколькими конфигурациями превратила последний в ад. С первым я потратил около часа, пытаясь выполнить все трюки с Superuser / Serverfault, чтобы принудительно выполнить обновление без перезагрузки, только для того, чтобы удвоить каждый путь для моей проблемы. - person Dan Is Fiddling By Firelight; 14.03.2016
comment
@DanNeely Это происходит (IIRC), потому что установка env vars не влияет на запущенные процессы, и если вы запускаете что-либо через проводник, он унаследует ранее существовавшую среду проводника. Я думаю, вы можете обойти это, выключив проводник и перезапустив его (или, в худшем случае, выйдите из системы/войдите в систему) - person FrozenKiwi; 14.03.2016
comment
Однако снова @DanNeely мы говорим о Git, работающем в командном окне, а не о службе или другом долго работающем / тяжеловесном процессе. - person GalacticCowboy; 14.03.2016
comment
Ребята, не хочу прерывать вас, но вам действительно не следует включать MSYS_NO_PATHCONV глобально/постоянно. Я обновлю ответ через минуту. - person Roman; 15.03.2016
comment
Спасибо, это полезно. Однако, похоже, он вызывает столько же вопросов, сколько и ответов. Хотя это работает в Git Bash, это не помогает, когда я использую PowerShell. Если он попытается это сделать, PS просто сообщит, что The term 'MSYS_NO_PATHCONV=1' is not recognized…, что имеет смысл, поскольку PS использует собственные пути Windows. Но это означает, что преобразование пути POSIX, которое кажется виновником при использовании Git Bash, не связано с PS. Так почему же я получаю одинаковые результаты независимо от того, какую оболочку использую? Есть ли совершенно другая проблема с PS, которая по совпадению приводит к тем же ошибкам? - person Carl Fink; 15.03.2016
comment
@CarlFink Синтаксис для установки переменных env в PowerShell отличается от bash (я думаю), отсюда и ошибка. Преобразование пути POSIX в Windows по-прежнему действует в PS. - person Roman; 15.03.2016

arrow_upward
2
arrow_downward

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

person Community    schedule 08.03.2016
comment
PowerShell автоматически добавляет .\ при завершении пути с помощью табуляции. Но результаты одинаковы в любом случае — Git сообщает, что есть no changes, когда они явно есть. - person Carl Fink; 09.03.2016
comment
git add -p без указания имени файла ничего не делает. Он не производит никакого вывода и просто возвращает подсказку. Ничего не постановочное. - person Carl Fink; 09.03.2016
comment
@ChristianGrabowski, как в Git Bash, так и в cmd.exe результаты одинаковы: git add -p вообще не выводит. - person Carl Fink; 09.03.2016
comment
Вы уверены, что файл редактируется и сохраняется правильно? Например, запустить diff в файле. - person Christian Grabowski; 09.03.2016
comment
@ChristianGrabowski Да, в файле есть фактические изменения, и они отображаются правильно, когда я запускаю git diff. - person Carl Fink; 09.03.2016
comment
Тогда файл был добавлен раньше или он новый? - person Christian Grabowski; 09.03.2016
comment
Это существующий файл, в который я внес изменения. - person Carl Fink; 09.03.2016