web-dev-qa-db-ja.com

git行末-隠したり、リセットしたり、偽の行末をリベースしたりすることはできません。

gitattributesを追加したレポがあり、問題なく作業していました。 Dropbox経由で別のマシンに同期します。私がそれを他のマシンに開いたとき、たくさんのファイルがステージングされていない領域に合計差分として突然現れました（すべてのファイルは行末を意味する巨大な差分です） diff）-私のcrlfエンディングは基本的に.* text=autoであり、ウィンドウで作業しています。変更を隠したり、ブランチをリセットしたりしようとしました。ついにファイルをコミットすることにし、行末がコミットする前に並べ替え（および押しつぶし）したい他のコミットを行いました。リベースしようとすると、次のようになります。

error: Your local changes to the following files would be overwritten by merge
        # those same files
Please, commit your changes or stash them before you can merge.
Aborting
Could not apply 89b25b81fff1a1e7893319e123aaaca9c4162a95... <commit message>

もちろん、隠し場所は機能しません

バグですか？

関連：

[〜＃〜] edit [〜＃〜]マシンとは何の関係もありません-同じマシン上でいくつかの（...）操作はそれらのファイルを作成するだけです（テキストとして.gitattributesにあります）「変更された」セクションに表示されます。存在すると思われる唯一の回避策は次のとおりです。

git rm --cached -r .
git reset --hard

注意して使用してください

編集：上記のハックはエイリアスステータスに移動しました：

[alias]
     crlf = !git rm -r . --cached -q && git reset --hard

UPDATE 2015.09.30：デュアルブート環境のWindows7およびArchLinuxから使用するNTFSパーティションにgitリポジトリがあります。ウィンドウをシャットダウンしてArchを起動すると、2つのファイル（html）が合計差分（行末差分）として表示されます。上記の回避策は機能しません-その間にGUIを更新するために数回適用しない限り...

私の.gitattributes：

* text=auto

*.py text diff=python
*.html text
.project text
*.pkl -text

# M$ files
*.bat text eol=crlf

# UNIX files
**/generate_second_post text eol=lf

# git files - have them with LF, as I edit them via the Shell (echo etc)
*.gitignore text eol=lf
*.gitattributes text eol=lf

[〜＃〜] nb [〜＃〜]：Linuxはコミット、ブランチの切り替えなどを許可しますが、リベースは許可しません-さらにそれらの差分常にgitk/gitguiに表示されます。

2018/12/14がMacに移動し、回避策が機能しなくなりました。 gitメーリングリストにメッセージを投稿しました： https://marc.info/?l=git&m=154482149623324&w=2

これが注目されることを期待しましょう

$ git --version
git version 2.19.2
gitline-endings
29
Mr_and_Mrs_D

最後に、5年後、TorstenBögershausenのおかげで完全な答えがここにあります。

このeolの状況をデバッグする方法は、TorstenBögershausenによって追加された -eol switch to git ls-files を使用して調査することです。問題のファイルはCRLFでコミットされたが、後で追加された.gitattributesファイルはこれらのファイルにtextを指定したことが判明しました。この結果 「違法な状態」で 。古いコミットの場合、何もする必要はありません。

すべきことは git add --renormalize . したがって、ファイルは正しい（lf）行末で追加されてから、リセットされます。これらの行末を作業ツリーに含めるのは困難です。

ただし、これは古いコミット（この違法な状態にあるコミット、つまりファイル間で間違った行末でコミットされ、gitattributesコミット）では役に立ちません-それらをチェックアウトすると、おそらくリセットできない変更につながります。これに対する修正は、@ iKlsRによる answer によって提供されます。

$ cat .git/info/attributes
"Mopy/Docs/Bash Readme Template.html" -text

理由は that ：

パスに割り当てる属性を決定するとき、Gitは$ GIT_DIR/info/attributesファイル（が最も優先度が高い）、. gitattributesファイルをパスと同じディレクトリに参照します。質問、および作業ツリーのトップレベルまでのその親ディレクトリ[ect]

（私の強調）

必ず行を追加してくださいafter再正規化しないと、ファイルは再正規化コミットに追加されません！

8
Mr_and_Mrs_D

今日、この問題が発生しました。この問題は、新しく追加された.gitattributesファイルに関連するいくつかのCRLF関連の問題が1行の* text=autoで発生しているように見えました。リベースまたは新しいブランチを作成すると、そのファイルはあなたに従い、その後の変更を台無しにするとともに、最初にコミットせずにそのブランチを離れることを防ぎます。

最初にこれを修正するには、一時的なブランチをチェックアウトし、ファイルを正常な状態に戻します（変更前）コミットしてから、ブランチ全体をリベースして最も古いコミットに戻し、外観を整えます。マスターのように。それはしばらくの間機能しましたが、その後同様のファイルがポップアップし、同じ修正が再び機能しませんでした。

最終的に私たちが行ったのは、opが彼のアップデートで共有したものと似ていました。.git/info/attributes内の1行とfile-to-remove -textは問題を軽減しているようです。これを行うことに悪影響があるかどうかわからないので、軽減すると言います。これは1つのファイルにも当てはまるため、まったく機能しない可能性があります。

4
iKlsR

これを試しましたか？

git add -u .
git reset
1
Attila Szeremi

同じ問題が今日私にも起こりました。これを試して

git config --local core.fileMode false

ここで説明するように： Gitにファイルモード（chmod）の変更を無視させるにはどうすればよいですか？

1
user2907467

これは私のWindows10 WSLでは機能しません。README.mdに差分があり、変更をプルできなかったので、これを

echo README.md >> .gitignore # not sure if this is needed
rm README.md # this need to be rm without git
git pull
git checkout .gitignore # to remove the change

私はあなたがただするならばそれもうまくいくと思います：

rm file
git checkout <branch>

しかし、私のリポジトリが現在機能しているため、テストできません。

0
jcubic

ここで同じ問題、私はWin7、sourceTree v3.0.9、gitv1.9.5を使用しています

リポジトリルートでは、.gitattributeファイルにtext = autoがあると、行末に関するローカルファイルの変更が多数表示され、何もできなくなります。 text = crlfを設定すると、ローカルでの変更はすべてなくなります。

以前、設定ファイルに「[core] autocrlf = false」を追加しようとしましたが、役に立ちませんでした。

2018年12月6日に更新：私のSourceTreeは古いバージョンの埋め込みgitを使用していました。SourceTreeで更新するだけで、すべてが.gitattributesの「text = auto」で機能するようになりました。

0
Yang