Приложение SourceTree сообщает о незапланированных изменениях даже для недавно клонированного хранилища - что может быть неправильным?

Удаленный репозиторий git просто клонирован в локальное поле, используя Atlassian SourceTree. Даже файлы не были изменены в дереве работы, Atlassian перечисляет кучу файлов сразу в разделе "Uncommitted changes". Каждый файл показывает один и тот же счет строки как снят, так и добавлен, и этот счет равен общему количеству строк в файле. Это как-то подскажет нам, что мы сталкиваемся с проблемой, связанной с окончанием строки.

Однако репозиторий .gitattribute содержит

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

что в статье GitHub Работа с окончанием строки должно явно указывать core.autocrlf true для репозитория. Однако также ~/.gitconfig содержит autocrlf = true.

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

Репозиторий клонирован в несколько местоположений и гарантирует, что файлы не были в одном и том же пути, чтобы убедиться, что SourceTree или git не помнят старые файлы.

Репозиторий взаимодействует с окнами Windows, Linux и OSX. Эта проблема появляется только в OSX.

Что еще может быть неправильным в настройке SourceTree/repository/ git?


Обновление №1, 20. апреля 2013 г.

Поскольку все еще что-то не так, здесь представлены частичные выходы git config --list.

В консоли SourceTree (OSX)

core.excludesfile=/Users/User/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"
mergetool.sourcetree.trustexitcode=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.autocrlf=true

Вот соответствующий вывод со стороны Windows:

core.symlinks=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.proxy=
core.autocrlf=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.eol=native
core.autocrlf=true

И полный .gitattributes для рассматриваемого репозитория

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

*.php    text
*.twig   text
*.js     text
*.html   text diff=html
*.css    text
*.xml    text
*.txt    text
*.sh     text eol=lf
console  text

*.png    binary
*.jpg    binary
*.gif    binary
*.ico    binary
*.xslx   binary

Ответ 1

Я один из разработчиков SourceTree (на самом деле я разрабатываю версию продукта Mac), поэтому надеюсь, что смогу помочь.

Машины Windows преобразуют CRLF в LF при совершении и LF в CRLF при проверке. autocrlf гарантирует, что все в LF находится внутри репозитория. Опция text = auto - это тот, который нам интересен, хотя он говорит в документах:

Когда текст установлен на "авто", путь указывается для автоматической нормализации окончательной строки. Если git решает, что контент является текстом, его окончание строки нормируется на LF при регистрации.

Итак, вы видите, что в режиме проверки он скажет: "Эй, мне нужно нормализовать эти строки, потому что они не в формате LF, а в CRLF". и, таким образом, изменяет вашу рабочую копию для выполнения работы, которую она должна выполнять. Обычно на Mac/Linux вам не нужно нормализовать, потому что все в LF, но git выполнит проверку, потому что вы могли бы проверить из репозитория, который был ранее разработан в Windows, или, возможно, в редакторе, который был используя CRLF вместо LF.

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

Если вы просто хотите иметь окончания строк CRLF в своем рабочем каталоге независимо от того, с каким репозиторием вы работаете, вы можете установить конфигурационную переменную "core.autocrlf" без изменения каких-либо атрибутов.

Хотя представьте, что предыдущая цитата была при установке autocrlf для определенного репозитория, а также во всем мире.

Надеюсь, что из какой-то помощи, если нет, не стесняйтесь задавать больше вопросов!


Здесь хорошая публикация SO post re: line: Почему я должен использовать core.autocrlf = true в Git?


ИЗМЕНИТЬ

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

  • Чтобы установить соответствующие параметры git в .git/config
  • Если вы хотите сохранить окончание строк CRLF, установите autocrlf=true
  • Если при проверке вашего репозитория вы не хотите, чтобы ваши окончания строк были автоматически преобразованы (в результате все ваши файлы были в "измененном" состоянии немедленно), установите для параметра text значение unset. Добавьте этот параметр, если для глобальной конфигурации git установлено значение, которое вы не хотите.
  • Если вы работаете как с Windows, так и с Mac для проекта, тогда вам лучше всего text=auto и убедитесь, что LF используется по всей доске. Вот почему проблемы, подобные этой ползучести; потому что ваш конфигуратор git отличается или потому что исходный проект /git в Windows предполагает CRLF, когда ваш Mac принимает LF.

Ответ 2

Я до сих пор не понимаю его на 100%, но для нас проблема заключалась в * text=auto в файле .gitattribute в репозитории. Я проверил, и мы уверены, что core.autocrlf=true установлен в каждом месте, где он может быть установлен для моего пользователя на ПК с ОС Windows. Я знал, что это тоже не проблема с SourceTree, так как TortoiseGit и просто Windows Git (msysgit) имели такую ​​же "проблему" для этого репозитория. Действительно странное поведение - я бы клонировал репо один раз и сразу увидел 11 "разных" файлов, затем я бы удалил и начал, а следующий клон имел бы 14 "разных" файлов.

Комментируя * text=auto в файле .gitattribute репозитория, все исправлено. Его почти как text=auto не ведет себя так же, как autocrlf=true, и последний отключается, если первый задан в файле .gitattribute. Но это не то, что, по-видимому, указывает каждый справочник.

Ответ 3

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

Примерно через час исследования мы обнаружили причину. Один из наших разработчиков * nix, скорее всего, ошибочно добавил файлы в папку с тем же именем, что и предназначенная, но имела разную капитализацию. * В средах nix можно было легко обращаться с этой новой папкой, но Windows (из-за нечувствительности к регистру) объединила две папки.

Итак, например, если у вас есть две папки, test и Test, каждая из которых имеет файл file.txt внутри, и эти два файла file.txt не идентичны, тогда Windows фактически копирует/заменяет один из них (не уверен который приказывает клонировать папки), таким образом "изменяя" файл и создавая незафиксированные изменения в "Test/file.txt" непосредственно после новой установки.

Пример:

test/
--file.txt (with contents of "This is a commit")

Test/
--file.txt (with contents of "This is a commit with some changes")

Это всегда будет показывать новые незафиксированные изменения, состоящие в добавлении слов "с некоторыми изменениями" в Test/file.txt при клонировании на машине Windows, в то время как машины на основе nix не будут иметь проблемы.

Это не обязательно относится к проблеме OP, но напрямую относится к вопросу в заголовке. Надеюсь, это поможет кому-то там.

Ответ 4

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

text = auto 
autocrlf = true

Ответ 5

Обычно эта строка в .gitattribute:

* text=auto

автоматически гарантирует, что все файлы, которые Git считает текстом, будут иметь нормализованные окончания строки (LF) в репозитории, даже если git config core.autocrlf установлено на false (по умолчанию). Поэтому Git автоматически изменяет файлы в соответствии с этими правилами.

Итак, у вас есть следующие возможности:

  • Предположим, что изменения нормализации правильны (насколько они сделаны для текстовых файлов) и просто передают их, например.

    $ git diff
    $ git commit -m "Introduce end-of-line normalization" -a
    
  • удалить/отключить автоматическую нормализацию из файла .gitattribute и reset файлов,

  • удалите индекс и повторно сканируйте файлы, например.

    $ rm -v .git/index # Or: git rm --cached -r .
    $ git reset --hard # Rewrite the Git index. Or: git add -u
    
  • в качестве альтернативы, что бы вы ни делали, попробуйте с силой (-f), например. git pull origin -f, git checkout master -f и т.д.,

  • используйте вместо командной строки git, так как это может быть проблемой с исходным приложением SourceTree.

Смотрите: Работа с окончаниями строк в документах GitHub.