web-dev-qa-db-ja.com

SourceTreeアプリは、新しくクローンされたリポジトリでもコミットされていない変更を行うと言っています-何が間違っているのでしょうか？

リモートgitリポジトリは、 Atlassian SourceTree を使用してローカルボックスに複製されます。作業ツリーで実際にファイルが変更されていない場合でも、アトラシアンは「コミットされていない変更」の下に多数のファイルをすぐにリストします。各ファイルには、削除と追加の両方で同じ行数が表示され、この数はファイル内の行の合計数に等しくなります。これは、何らかの形で行末の問題にぶつかっているというヒントを提供します。

ただし、リポジトリの.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年4月

まだ何か問題があるので、ここに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
gitend-of-lineatlassian-sourcetree
40
Ville Mattila

私はSourceTreeの開発者の1人です（実際にはMacバージョンの製品を開発しています）。

Windowsマシンは、CRLFをLFにコミットし、LFをチェックアウト時にCRLFに変換します。autocrlfは、すべてがLFオプションtext = autoは、それでも興味があるものです ドキュメントに記載されている ：

テキストが「auto」に設定されている場合、パスは自動行末正規化用にマークされます。 gitがコンテンツがテキストであると判断した場合、その行末はチェックイン時にLFに正規化されます。

したがって、チェックイン時に「ねえ、これらの行末はLF形式ではなくCRLFにあるので正規化する必要があります。」と表示され、作業コピーを変更します通常、Mac/Linuxでは、すべてがLFにあるため正規化する必要はありませんが、Gitは以前にWindowsで開発されたリポジトリからチェックアウトした可能性があるため、チェックを行います。 LFの代わりにCRLFを使用していたエディターで。

つまり、LF形式である必要がありますが、autocrlf = true（編集、常にtrueに！）する必要があるため、すべてのファイルを再コミットすることをお勧めします。 ）ドキュメントに記載されているように、Windowsリポジトリで：

作業しているリポジトリに関係なく、単に作業ディレクトリにCRLF行末を置きたい場合は、属性を変更せずに構成変数「core.autocrlf」を設定できます。

以前の引用は、特定のリポジトリおよびグローバルにautocrlfを設定するときだったと想像してください。

うまくいけば、それが助けになることを願っています。

良いSO post re：行末： Gitでcore.autocrlf = trueを使用する必要があるのはなぜですか？

[〜＃〜] edit [〜＃〜]

上記の回答に基づいて、ここでいくつかのことを確認する必要があります。

  • .git/configで関連するgitオプションを設定したこと
  • CRLF行末を保持する場合は、autocrlf=trueを設定します
  • リポジトリをチェックアウトするときに、行末を自動的に変換したくない場合（すべてのファイルをすぐに「変更済み」状態にする）、textオプションをunset。グローバルgit configで必要でない値に設定されている場合、このオプションを追加します。
  • プロジェクトでWindowsとMacの両方で作業している場合は、text=autoを用意し、LFが全面的に使用されていることを確認することをお勧めします。 ; git configが異なるため、またはWindowsでのプロジェクト/ gitの初期セットアップは、MacがLFを想定しているときにCRLFを想定しているためです。
38
Kezzer

私はまだそれを100％理解していませんが、私たちにとって問題はリポジトリの* text=autoファイルの.gitattributeでした。私はチェックしましたが、Windows PC上のユーザーに設定できるすべての場所でcore.autocrlf=trueを確実に設定しています。 TortoiseGitとWindows Git（msysgit）のすべてがこのリポジトリに対して同じ「問題」を抱えていたため、これもSourceTreeの問題ではないことを知っていました。本当に奇妙な振る舞い-リポジトリを一度クローンして、すぐに11の「異なる」ファイルを確認してから、削除して最初からやり直し、次のクローンには14の「異なる」ファイルがあります。

リポジトリの* text=autoファイル内の.gitattributeをコメントアウトすると、すべてが修正されました。そのほとんどtext=autoはautocrlf=trueと同じように動作せず、最初のファイルが.gitattributeファイルで設定されている場合、後者は無効になります。しかし、それはすべてのオンラインガイドが示しているように見えるものではありません。

11
Adam Nofsinger

構成ファイルに次の両方の行を追加しました。私がやった他のことは、「Staged Files」チェックボックスをクリックしてからクリックを解除することで、すべてが更新されました。がんばろう。

text = auto 
autocrlf = true
1
vr_driver

通常、.gitattributeのこの行：

* text=auto

git config core.autocrlfがfalse（デフォルト）に設定されている場合でも、Gitがテキストと見なすすべてのファイルがリポジトリ内で正規化された（LF）行末を持つようにします。したがって、Gitはこれらのルールに従ってファイルを自動的に変更します。

したがって、次の可能性があります。

  • 正規化の変更が正しいと仮定し（テキストファイルに対して行われている限り）、単にコミットします。

    $ git diff
$ git commit -m "Introduce end-of-line normalization" -a

  • .gitattributeファイルから自動正規化を削除/無効にし、ファイルをリセットします。

  • インデックスを削除し、ファイルを再スキャンします。

    $ 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など、

  • sourceTreeアプリ自体に問題がある可能性があるため、代わりにgitコマンドラインを使用します。

参照： 行末を扱う GitHub docs.

0
kenorb

ちょうどこの問題に遭遇しました。新鮮なクローンは、コミットされていないだけでなく、実際の新しいコードの多くの行を持ついくつかのファイルをプルします。 git reflogは何も示しませんでした。実際のコミットではなかったため、切り離されたHEADは問題ではありませんでした。

約1時間の調査の後、原因を見つけました。私たちの* nix開発者の1人は、おそらく誤って、意図した名前と同じ名前であるが大文字が異なるフォルダーにファイルを追加しました。 * nix環境ではこの新しいフォルダーを簡単に処理できましたが、Windowsでは（大文字と小文字が区別されないため）2つのフォルダーがマージされました。

したがって、たとえば、testとTestの2つのフォルダーがあり、それぞれにfile.txtが含まれていて、これらの2つのfile.txtファイルが同一でない場合、Windowsは実際にそれらの1つをコピー/置換します（順序はわかりません）フォルダーのクローンを作成します。したがって、新規インストールの直後にファイルを「変更」し、「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")

これにより、Windowsマシンでクローンを作成するときにTest/file.txtに「with some changes」という単語を追加することで構成される新しいコミットされていない変更が常に表示されますが、* nixベースのマシンには問題はありません。

これは必ずしもOPの問題に対処するものではありませんが、タイトルの質問に直接関連しています。うまくいけば、そこにいる誰かを助けます。

0
Colt McCormack