Почему не работает git diff

«git diff» ничего не делает

Я предполагаю, что это ошибка конфигурации где-то, но я не могу понять, где. Регулярные команды git, похоже, работают нормально, но «git diff» ничего не делает. Чтобы быть в безопасности, я удалил внешние инструменты diff из моего .файл gitconfig хранит настройки. Это было установлено через MacPorts и является версией lates (1.7.2.2).

Я вижу, что когда я запускаю «git diff» из своего рабочего пространства, он просто выходит, ничего не делая.

Если я создаю резервную копию одного каталога, из моей корневой рабочей области, набрав «git diff» дает мне это:

Это может быть ожидаемым поведением, так как я не нахожусь под репозиторием git.

любые идеи о том, что я могу сделать для устранения этого?

5 ответов

вывод по умолчанию для git diff список изменений, которые не были зафиксированы / добавлен в индекс. Если нет изменений, то нет и выходных данных.

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

посмотреть документация для получения более подробной информации. В частности, прокрутите вниз до примеров и прочитайте этот раздел:

1. Diff рабочая копия с индексом
2. Diff индекс с головой
3. Diff рабочая копия с головой

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

когда пользователь вводит » git diff » вне рабочего дерева, думая, что он внутри одного, текущее сообщение об ошибке, которое является однострочным:

может быть недостаточно, чтобы заставить его осознать ошибку.

добавить » Not a git repository » к сообщению об ошибке, когда мы попали в » —no-index режим» без явного опция командной строки, чтобы проинструктировать нас сделать это.

• совершить 286bc123cd (gitster, Junio C Hamano), который поясняет, что git diff —no-index может действовать как обычный (не-git) diff .
• совершить b214eddfb2 (Дейл Р. Уорли), который уточняет сообщение об ошибке:

уточнить документации для » diff —no-index «.
Состояние, когда не внутри a хранилище, —no-index подразумевается и два аргумента обязательный.

уточнить сообщение об ошибке из diff-no-index сообщить пользователю, что CWD не находится внутри репозитория, и поэтому два аргумента являются обязательными.

Он ничего не делает, если ваш рабочий каталог чист и нет никаких отличий от последнего обновления. Попробуйте отредактировать файл, а затем снова запустите git diff, и он должен показать diff.

Если вы используете его вне реального репозитория или рабочей копии, его поведение идентично GNU diff. Поэтому вам нужно сообщить 2 каталога или файла для сравнения. Пример:

git diff old_dir new_dir .

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

Не в вашем случае, но, возможно, потому, что файл, который вы передаете, не существует

Источник

Почему `git diff ‘ не вызывает внешний инструмент diff?

В моем репозитории, если я наберу

Я получаю дисплей в терминале diff. Я думаю, что этого не должно произойти, потому что я настроил внешний инструмент diff, как показано на выходе git config -l :

Файл git-diff, на который ссылается строка diff.external , выглядит следующим образом

Почему git diff не вызывает meld?

Я получаю то же самое поведение, если я настраиваю вещи так, что git config -l имеет следующее строка:

Примечание : другие репозитории на моей машине не имеют этой проблемы.

Связанные, но не эквивалентные, поэтому вопросы:

3 ответов:

Я получаю дисплей в терминале diff. I этого не должно произойти, потому что я настроил внешний инструмент diff

Да, должно быть: diff.external — Это Для «in-terminal diff display».

Если эта переменная конфигурации задана, тогенерация diff выполняется не с помощью внутреннего механизма diff, а с помощью данной команды .
Может быть переопределен с помощью среды GIT_EXTERNAL_DIFF переменная.
Команда вызывается с параметрами, как описано в разделе «Git Diffs» в git(1). Примечание: Если вы хотите использовать внешнюю программу diff только для подмножества ваших файлов, вы можете использовать gitattributes(5) вместо этого.

Вопрос, который вы связываете , объясняет, почему meld не сможет играть роль «внешнего различия».

meld может быть настроен на Windows как difftool: смотрите » git Diff и Meld на Windows».

Создайте файл с именем git-diff.sh , используя следующее содержимое:

Сохраните его в таком месте, как /usr/local/bin , предоставив ему права исполняемого файла:

Последний шаг-открыть ваш файл $HOME/.gitconfig и добавить следующее несколько строк:

В следующий раз, когда вы введете git diff в проект Git с изменениями, Meld будет запущен, показывая вам средство просмотра различий с разделенной панелью.
Обратите внимание, что перед открытием следующего средства просмотра различий необходимо закрыть открытый экземпляр meld.

Похоже, что git diff (по крайней мере, начиная с версии git 1.7.12.4 ) не будет запускать ничего, кроме внутреннего, консольного diff на файле, который находится в состоянии «оба модифицированы». Однако git mergetool работает с такими файлами.

Обычно я просто хочу проверить, являются ли изменения, которые я собираюсь проверить, правильными. Поэтому я следовал процедуре, предложенной здесь (аналогичной той, которую отметил VonC). Однако запуск git difftool все еще не открыл meld. Затем я создал псевдоним:

Сохраните это в своем .bashrc или .zshrc или соответствующий конфигурационный файл для вашей оболочки. Это существенно сравнивает состояние ветви с предыдущей фиксацией на ветви.

Сделайте git-diff , чтобы увидеть изменения в файле на файл basis или git-diff —dir для просмотра всех изменений в представлении каталога.

Источник

Почему git не распознает, что мой файл был изменен, поэтому git add не работает

Я пытаюсь отправить свои файлы в github с помощью bash. Они уже там, и я загружаю более новую версию с новыми строками, кодом и т. Д. Но когда я пытаюсь, git add а потом появляется сообщение git status :

ничего не фиксировать, рабочий каталог чист

И файл, который я использую, был только что изменен.

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

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

Если это не поможет, сброса может быть достаточно для других странных случаев.

На практике я обнаружил, что удалил кешированный файл и заставил его работать:

В git rm —cached средстве для только удалить файл из индекса, и reset говорит мерзавец перезагрузить индекс GIT от последней фиксации.

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

Это случилось со мной, когда у меня была аналогичная проблема.

Как уже говорилось, файлы, вероятно, были помечены флажком «предположить-без изменений», который в основном сообщает git, что вы не будете изменять файлы, поэтому ему не нужно отслеживать изменения с их помощью. Однако это может повлиять на несколько файлов, и если это большое рабочее пространство, вы можете не захотеть проверять их все по одному. В этом случае вы можете попробовать: git update-index —really-refresh

По сути, это заставит git отслеживать изменения всех файлов, независимо от флагов «предполагать без изменений».

Звучит безумно, но иногда вы не в правильном репо, даже если думаете, что это так. Например, вы могли переместить родительский каталог, но забыли переключить репозиторий в текстовом редакторе. Или наоборот: вы находитесь в правильном репозитории в текстовом редакторе, но не в том репозитории в командной строке. В первой ситуации вы вносите изменения в правильный файл, но это не та папка, которая открыта в вашей командной строке, поэтому на самом деле это не тот файл. Во второй ситуации вы действительно отредактировали правильный файл, но git вашей командной строки не распознает изменение, потому что вы находитесь не в правильном каталоге в командной строке.

Что ж, у нас недостаточно ответов на этот вопрос, поэтому я дам вам несколько предположений:

1) вы сохранили свои изменения, чтобы исправить тип: git stash pop

2) у вас были изменения и вы их зафиксировали, вы должны увидеть свою фиксацию в git log

3) у вас были какие-то git reset —hard изменения, ваши изменения могут быть там в журнале ссылок, введите, git reflog —all а затем проверьте или выберите ссылку, если вы когда-нибудь ее найдете.

4) вы проверяли одно и то же репо несколько раз и ошиблись.

Произошла такая странная вещь. Плагин Eclipse Kepler git автоматически отмечал все мои папки проекта как игнорируемые в папке .gitignore.

Когда я заходил commit в Team меню, все они снова игнорировались. Насколько я могу судить, это произошло потому, что я установил их как производные в родительском проекте. Снятие отметки с них как dervied исправлено. Я никогда раньше не видел этого на Индиго. Надеюсь, это кому-то поможет.

TL; DR; Вы вообще находитесь в правильном репозитории?

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

На самом деле на моей машине, у меня было два отдельных GIT репозиториев repo1 и repo2 настроен в том же корневом каталоге с именем source . Эти два репозитория по сути являются репозиториями двух продуктов, над которыми я работаю в своей компании. Дело в том, что, как правило, структура каталогов исходного кода всех продуктов в моей компании одинакова.

Поэтому, не осознавая, я изменил файл с точно таким же именем, в repo2 котором я должен был изменить repo1 . Таким образом, я просто продолжал работать команду git status на repo1 и продолжал давать то же сообщение

ничего не фиксировать, рабочий каталог чист

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

Источник

Статус Git показывает файлы как измененные, даже если содержимое одинаковое

я получил проверку git от кого-то другого и пытаюсь зафиксировать неустановленные изменения в локальном репозитории. Однако,много (если не каждый) файл отображается как изменен хотя содержимое точно такое же.

Я уже поставил core.fileMode false, а также установить core.autocrlf false, то без успеха.

стоит отметить, что Git repo, который я получил, был от кого-то, кто использует Windows, в то время как я использую Линукс.

что я могу сделать, чтобы совершить фактический изменения?

EDIT: вывод git config -l :

Update: добавлены некоторые случайные примеры файлов. Эти файлы являются текстовыми, так легче включать.

оригинальные файлы находятся здесь:https://gist.github.com/c3c5302430935155ef3d. Hexdumps определенно указывают, что файлы отличаются, но я понятия не имею, что вызывает это, и как это исправить.

13 ответов

Update: согласно комментарию к этому вопросу, проблема была решена:

это легко: первый файл имеет crlf-строки (windows), второй LF (Unix). The file util (доступно в git\usr\bin) покажет вам, что ( file a b ответим что-то вроде a: ASCII text, with CRLF line terminators b: ASCII text )

оригинальный ответ ниже:

разница вам показать не не показать одну другую строку. Мочь Вы пост .в git/config (или лучше git config -l ).

возможно, у вас есть пробелы, игнорирующие активированные

вы должны попытаться отключить core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol ;

может использоваться для проверки того, что файлы на самом деле разные. Использование внешнего diff также может работать

Я решил эту проблему, используя следующие stpes

1) Удалите каждый файл из индекса Git.

2) перепишите индекс Git, чтобы забрать все новые окончания строк.

обратите внимание, что Шаг 2 может удалить ваши локальные изменения. Решение было частью шагов, описанных на сайте git https://help.github.com/articles/dealing-with-line-endings/

У меня была та же проблема. после win — >Lin copy у меня все файлы изменены.
я использовал fromdos для исправления окончаний строк
а потом . —2—>

для добавления изменения.
он добавил 3 файла (не все из них), которые я фактически изменил. а после этого . —3—>git статус показывает только 3 измененные файлы. после git commit все в порядке с git status

вы изменили режим файлы? Я сделал это на своей машине, и локальная машина dev дала 777 всем файлам, тогда как у РЕПО был 755, который показал каждый файл как измененный. Я сделал git diff и он показал, что старый режим и новый режим отличаются. Если это проблема, то вы можете легко игнорировать их git config core.filemode false
Ура!—4—>

однако многие (если не все) файлы отображаются как измененные, даже если содержимое точно такое же.

С git 2.8 (март 2016) вы сможете быстро проверить, связаны ли эти изменения с eol.

ls-files : добавить диагностику eol

при работе в кросс-платформенной среде пользователь может захотеть проверить, нормализованы ли текстовые файлы в репозитории и если .gitattributes установлены соответствующим образом.

позволяет Git показывать окончания строк в индексе и в рабочем дереве и эффективные атрибуты text/eol.

конец строки (» eolinfo «) показаны как это:

атрибут effective text/eol является одним из следующих:

git ls-files —eol дает такой вывод:

чтобы показать, какое соглашение eol используется в данных в индексе (‘ i ‘), и на рабочем дереве (‘ w ‘), и какой атрибут действует, для каждого пути, который показал.

я смог исправить проблемы на машине Windows, изменив ядро.autocrlf от ложного ядра.autocrlf=вход

в моем случае файлы появились как измененные после изменение прав доступа к файлам.

чтобы git игнорировал изменения разрешений, выполните следующие действия:

на git FAQ имеет ответ, который может быть актуальным, хотя я никогда не сталкивался с этим раньше:

почему git diff иногда перечисляет файл, который не имеет изменений?

git diff и другие операции git оптимизированы, поэтому он даже не смотрит на файлы, чей статус (размер, время модификации и т. д.) На диске и в индексе git отличаются. Это делает git diff чрезвычайно быстрым для небольших изменений. Если файл был затронут так или иначе, git diff должен смотреть на содержание и сравнивать его, что является гораздо более медленной операцией, даже когда на самом деле нет изменений. git diff перечисляет файлы как напоминание о том, что он не используется оптимально. Запуск git status не только покажет статус, но и обновит индекс со статусом для неизмененных файлов диска, делая последующие операции, а не только diff, намного быстрее. Типичный случай, который вызывает много файлов, которые будут перечислены diff работает команды массового редактирования, как perl-pi-e ‘. ‘.

что значит git status показать для вас?

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

Итак, я попробовал почти все здесь и хочу внести еще одно решение, которое исправило все мои проблемы. Мои проблемы не были с окончаниями строк или фактическими разрешениями или чем-то подобным. Это было потому, что я установил Cygwin и целый ряд вещей, которые поставляются с этим, которые без моего ведома также установили свою собственную версию git. Я никогда не замечал этого, просто у меня были странные проблемы с пользователями и файлами, помеченными как измененные (из-за perms изменения.)

оказывается, я понял это, потому что думал, что я должен просто обновить Git до последней версии, что я и сделал, но работает git —version вернул старый номер версии. После последующей охоты за Почему, я нашел корень каталога cygwin bin в моем пути к среде, который содержал исполняемый файл git, работающий под старым номером версии. Иди разберись.

Это также было трудно найти, потому что у меня установлен TortoiseGit. Мои инструменты командной строки будут использовать cygwin версия из-за отступлений пути, и TortoiseGit был настроен на использование версии windows, что делает его еще более запутанным.

надеюсь, это кому-то поможет.

вот как я исправил проблему в Linux, когда я клонировал проект, который был создан в Windows:

в linux, чтобы все работало правильно, вы должны иметь этот параметр: core.autocrlf=вход

вот как его установить: git config —global core.autocrlf вход

затем снова клонируйте проект из github.

единственная подозрительная запись в вашей конфигурации выглядит для меня core.ignorecase . Вы можете попробовать расстроить это с помощью:

. и посмотрите, если выход из git status или git diff — разному.

Если у вас есть несколько ветвей и все изменения нажаты, то это решение может работать

просто добавьте и зафиксируйте все изменения, которые вы видите, в текущую ветку (скажем, master). Затем проверьте другую ветку (скажем, тест). Удалите главную ветвь локально (с параметром-D). Вытащите главную ветку из git

Источник