Совместное использование символьных ссылок git repo между Windows и WSL - PullRequest
Новая
       14

Совместное использование символьных ссылок git repo между Windows и WSL

0 голосов
/ 08 июня 2019

У меня есть следующие настройки:

  • WSL установлен с Ubuntu, там уже установлен git
  • git установлен от https://git -scm.com на стороне Windows
  • Создание символической ссылки включается путем включения режима разработчика и добавления моего пользователя в правильную группу политик, как описано в https://github.com/git-for-windows/git/wiki/Symbolic-Links
  • core.symlinks=true (из-за вышеуказанной строки)
  • core.autocrlf=false (я не хочу, чтобы git делал какие-то хитрости, я делю репозиторий между Windows и WSL)

Это почти отлично работает (очень впечатлило). Когда я клонирую репозиторий, в Windows и WSL все нормально, кроме символических ссылок на одной из двух сторон, которые говорят, что они изменены, но это не так. С обеих сторон символические ссылки работают правильно, я могу перемещаться по ним без проблем.

После первоначального клонирования (на стороне Windows) Windows PowerShell выдает: 

PS C:\Users\Matthew\Projects\...> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Однако на стороне WSL написано, что две символические ссылки изменены: 

/mnt/c/Users/Matthew/Projects/...$ git status 
On branch master 
Your branch is up to date with 'origin/master'.

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:   t/browser 
        modified:   web/jslib

no changes added to commit

Но git diff не выдает: 

/mnt/c/Users/Matthew/Projects/...$ git diff
/mnt/c/Users/Matthew/Projects/...$

Если я затем сброшу проверку на стороне WSL, все переключится: 

/mnt/c/Users/Matthew/Projects/...$ git reset --hard HEAD 
HEAD is now at ......... Commit message here
/mnt/c/Users/Matthew/Projects/...$ git status 
On branch master 
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

И обратно на Windows Powershell: 

PS C:\Users\Matthew\Projects\...> git status
On branch master
Your branch is up to date with 'origin/master'.

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:   t/browser
        modified:   web/jslib

no changes added to commit (use "git add" and/or "git commit -a")
PS C:\Users\Matthew\Projects\...> git diff
PS C:\Users\Matthew\Projects\...>

Похоже, git устанавливает внутренний флаг, который он считает измененным в другой системе; Есть ли способ исправить или обойти это?

1 Ответ

0 голосов
/ 08 июня 2019

Эта проблема возникает из-за того, что Windows и Linux (или, по крайней мере, эмулируемая версия) не согласны с размером символической ссылки.В Windows размер символьной ссылки указывается в блоках, поэтому символьная ссылка из 6 символов будет иметь размер 4096 байт.В Linux размер символической ссылки - это число байтов, которые она содержит (в данном примере 6).

Одна из вещей, которую Git записывает в индекс для отслеживания изменения файла, - это размер.Когда вы выполняете какое-либо обновление индекса, например, с помощью git reset --hard, Git записывает все эти метаданные в индекс, включая размер.Когда вы запускаете git status, git проверяет эти метаданные, чтобы определить, совпадают ли они, и, если нет, помечает файл как измененный.

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

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

...