файлы, отображаемые как измененные сразу после git clone

<p>у меня сейчас проблема с репозиторием, и, хотя мой git-fu обычно хорош, я не могу решить эту проблему. </p><p>когда я клонирую этот репозиторий, а затем перехожу в репозиторий, git-status показывает несколько файлов, которые были изменены. примечание: я не открывал репо в каком-либо редакторе или чем-то еще. </p><p>я пытался следовать этому руководству: <a href="http://help.github.com/dealing-with-lineendings/">http://help.github.com/dealing-with-lineendings/</a> , но это никак не помогло с моей проблемой.</p><p>я пробовал <code>git checkout -- .</code> много раз, но, похоже, ничего не делал.</p><p>любая помощь/идеи будут с благодарностью</p><p>обновление 1: я на mac, и в самом репо нет подмодулей.</p><p>обновление 2: файловая система является файловой системой «журналированная hfs +» на mac и не чувствительна к регистру. файлы состоят из одной строки и около 79k каждый (да, вы правильно поняли), поэтому просмотр <code>git diff</code> не особенно полезен. я слышал о выполнении <code>git config --global core.trustctime false</code>, которое может помочь, которое я попробую, когда вернусь к компьютеру с репо.</p><p><strong>обновление 3:</strong> изменил детали файловой системы с фактами! и я попробовал трюк <code>git config --global core.trustctime false</code>, который не очень хорошо работал.</p>

<p>я понял. все остальные разработчики работают на ubuntu (я думаю) и, следовательно, имеют чувствительные к регистру файловые системы. я, однако, не (как я на mac). действительно, у всех файлов были строчные двойники, когда я взглянул на них, используя <code>git ls-tree head <path></code>.</p><p>я возьму одного из них, чтобы разобраться.</p>

<p>у меня была такая же проблема на mac после клонирования репозитория, он предполагал, что все файлы были изменены.</p><p>после запуска <code>git config --global core.autocrlf input</code> он все еще помечал все файлы как измененные. после поиска исправления я наткнулся на файл <code>.gitattributes</code> в домашнем каталоге, в котором было следующее.</p><pre><code>* text=auto </code></pre><p>я прокомментировал это, и любые другие клонированные репозитории отныне работают нормально. надеюсь, это кому-нибудь поможет.</p>

<pre><code>git config core.filemode false </code></pre><p>решил эту проблему в моем случае</p><p> <a href="https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html">https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html</a> </p><p>tl; dr;</p><p>core.filemode</p><p>если false, различия исполняемого бита между индексом и рабочим деревом игнорируются; полезно на сломанных файловых системах, таких как fat. смотрите git-update-index (1).</p><p>значение по умолчанию - true, за исключением того, что git-clone (1) или git-init (1) будут проверять и устанавливать core.filemode false, если это необходимо, при создании хранилища.</p>

<p>я предполагаю, что вы используете windows. на той странице github, на которую вы ссылаетесь, есть детали в обратном направлении. проблема в том, что окончания строк crlf уже переданы в репозиторий, а поскольку для <strong>core.autocrlf</strong> установлено значение <strong>true</strong> или <strong>input</strong>, git хочет преобразовать окончания строк в lf, поэтому <code>git status</code> показывает, что каждый файл изменен.</p><p>если это репо, к которому вы хотите получить доступ, но не имеете к нему никакого отношения, вы можете выполнить следующую команду, чтобы просто скрыть проблему, фактически не решая ее.</p><pre><code>git config core.autocrlf false </code></pre><p><hr> если это репо, в котором вы будете активно участвовать и можете вносить изменения. вы можете решить проблему, сделав коммит, который изменяет все окончания строк в репо на использование lf вместо crlf, а затем предпринимает шаги, чтобы предотвратить его повторение в будущем.</p><p>следующая информация взята непосредственно из справочной страницы <a href="http://git-scm.com/docs/gitattributes">gitattributes</a> и должна быть предварительно сформирована из чистого рабочего каталога.</p><pre><code>echo "* text=auto" >>.gitattributes rm .git/index # remove the index to force git to git reset # re-scan the working directory git status # show files that will be normalized git add -u git add .gitattributes git commit -m "introduce end-of-line normalization" </code></pre><p>если какие-либо файлы, которые не должны быть нормализованы, отображаются в состоянии git, удалите их текстовый атрибут перед запуском <code>git add -u</code>.</p><pre><code>manual.pdf -text </code></pre><p>и наоборот, для текстовых файлов, которые git не обнаруживает, можно включить нормализацию вручную.</p><pre><code>weirdchars.txt text </code></pre>

<p>пожалуйста, выполните следующие команды. это может решить проблему.</p><pre><code># remove everything from the index. git rm --cached -r . # write both the index and working directory from git's database. git reset --hard </code></pre>

<p>в visual studio, если вы используете git, вы можете автоматически генерировать файлы .gitignore и .gitattributes. автоматически сгенерированный файл .getattributes имеет следующую строку:</p><pre><code>* text=auto </code></pre><p>эта строка находится в верхней части файла. нам просто нужно было закомментировать строку, добавив знак # в начале. после этого все заработало как положено.</p>

<p>проблема также может возникнуть из-за различий в<strong> разрешений на доступ к файлам </strong>, как и в моем случае:</p><p>свежий клонированный репозиторий (windows, cygwin):</p><pre><code>$ git ls-tree head 100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile ↑↑↑ голый удаленный репозиторий (linux):$ git ls-tree head 100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile ↑↑↑ </code></pre>

<p>у меня такая же проблема. также с mac. глядя на репозиторий на машине с linux, я заметил, что у меня есть два файла:</p><p>geoip.dat и geoip.dat</p><p>удалил устаревший на linux-машине и снова клонировал репозиторий на mac. я не смог вытащить, зафиксировать, спрятать или вытащить из своей копии хранилища, когда были дубликаты.</p>

<p>я хотел добавить ответ, более направленный на «почему», это происходит, потому что уже есть хороший ответ, как это исправить.</p><p>итак, <code>.gitattributes</code> имеет настройку <code>* text=auto</code>, которая вызывает эту проблему.</p><p>в моем случае файлы в основной ветке github имели окончания <code>\r\n</code>. я набрал настройки репо для регистрации с окончаниями <code>\n</code>. я не знаю, что git проверяет, хотя. предполагается, что на моем компьютере с linux есть исходные окончания (<code>\n</code>), но я предполагаю, что он извлек файл с окончаниями <code>\r\n</code>. git жалуется, потому что он видит извлеченные окончания <code>\r\n</code>, которые были в репо, и предупреждает меня, что он проверит в настройках <code>\n</code>. следовательно, файлы «должны быть изменены».</p><p>это мое понимание на данный момент.</p>

<p>редактировать файл с именем: <code>sudo gedit .git/config</code> <code>sudo vim .git/config</code> </p><pre><code>[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true [remote "origin"] url = kharadepramod@bitbucket.org:digitalplumbing/unicorn-magento.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "productapproval"] remote = origin merge = refs/heads/productapproval </code></pre><p>изменить<strong> filemode = true </strong>в<strong> filemode = false </strong></p>

<p>у меня тоже была такая же проблема. в моем случае я клонировал репозиторий, и некоторые файлы сразу исчезли. </p><p>это было вызвано тем, что путь к файлу и имя файла были слишком длинными для windows. чтобы решить эту проблему, клонируйте репозиторий как можно ближе к корню жесткого диска, чтобы уменьшить длину пути к файлу, например. клонировать его в c:\a\gitrepo вместо c:\users documents\yyy\desktop\gitrepo</p>

<p>я скопировал свой локальный репозиторий в другую папку, и появилась куча измененных файлов. мой обходной путь:<strong> я спрятал измененные файлы и удалил тайник </strong>. хранилище стало чистым.</p>

<p>на случай, если это поможет кому-то еще, для этой проблемы может быть другая причина: разные версии git. я использовал установленную по умолчанию версию git на коробке с ubuntu 18.04 (bionic beaver), и все работало нормально, но при попытке клонировать хранилище с помощью git на ubuntu 16.04 некоторые файлы показывались как измененные.</p><p>ни один из других ответов здесь не устранил мою проблему, но обновление версий git для соответствия в обеих системах решило проблему.</p>

<p>та же проблема для меня. я мог видеть несколько изображений с одинаковыми именами, такими как «textfield.png» и «textfield.png», в удаленном репозитории git, но не в моем локальном репо, я мог видеть только «textfield.png», который не использовался в код проекта . оказывается, большинство моих коллег используют ubuntu с файловой системой ext4, а я на mac с apfs.</p><p>благодаря <a href="https://stackoverflow.com/a/5022417/2485238">сэму эллиотту</a> , решение было довольно простым. сначала я попросил коллегу по ubuntu удалить избыточные версии файлов с заглавными буквами, затем зафиксировать и нажать на удаленном.</p><p>затем я запустил следующее: </p><pre><code># remove everything from the index. git rm --cached -r . # write both the index and working directory from git's database. git reset --hard </code></pre><p>наконец, мы решили, что каждый разработчик должен изменить свою конфигурацию git, чтобы это никогда не повторилось</p><pre><code># local git config git config core.ignorecase = true </code></pre><p>или же </p><pre><code># global git config git config --global core.ignorecase = true </code></pre>

<p>я обнаружил, что git рассматривал мои файлы (в данном случае .psd) как текст. установка в двоичный тип в .gitattributes решила это.</p><pre><code>*.psd binary </code></pre>

<p>для новых версий macos это может быть вызвано функцией безопасности ос.</p><p>в репозитории, над которым я работал, был бинарный файл с * .app в качестве типа файла . это были просто некоторые сериализованные данные, но macos рассматривает все файлы * .app как приложение, и этот файл не был загружен пользователем система сочла это небезопасным и добавила атрибут файла <code>com.apple.quarantine</code>, который гарантирует, что файл не может быть выполнен.</p><p>но установка этого атрибута в файле также изменяла файл, и поэтому он отображался в наборе изменений git без какого-либо способа его возврата.</p><p>вы можете проверить, есть ли у вас такая же проблема, запустив <code>$ xattr file.app</code></p><p>решение довольно простое, если вам не нужно работать с файлом . просто добавьте <code>*.app binary</code> к вашему <code>.gitattributes</code></p>

<p>у меня была похожая проблема, и я нашел этот вопрос.</p><p>я пытался сделать интерактивный ребаз, но он утверждал, что были некоторые измененные файлы, поэтому он не позволил мне сделать это прямо сейчас. я пытался все, чтобы вернуться к чистому репо, но ничего не получалось. ни один из других ответов не помог. но это, наконец, сработало ...</p><pre><code>git rm -rf the-folder-with-modified-stuff git ci -m 'wat' </code></pre><p>boom! чистое репо. задача решена. затем мне просто пришлось отбросить последний коммит, когда я сделал свой <code>rebase -i</code>, и, наконец, все снова стало чистым .. странно!</p><p>но я добавляю это решение здесь, так что, возможно, если я когда-нибудь столкнусь с этим снова, я увижу это и попробую. спасибо</p>