Hello,
git config config core.autocrlf changes the index file, apparently making obsolete its contents when a repository is cloned. Run the following script:
# create a bare repository, empty rm -rf rel.git mkdir rel.git cd rel.git git init --bare git config core.autocrlf false cd -
# populate the bare repository rm -rf temp git clone rel.git temp cd temp echo aaa>f1 git add f1 git commit -m A git push origin master cd - rm -rf temp
# clone then the bare repository rm -rf int mkdir int git clone rel.git int cd int git status git ls-files -s --debug # (1) # change then core.autocrlf in the config git config core.autocrlf false git status git ls-files -s --debug # (2) cd -
At (1), git status reports "nothing to commit", but at (2) it reports:
On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)
modified: f1
no changes added to commit (use "git add" and/or "git commit -a")
The two git ls-files -s --debug commands report also differences in the index.
This seems rather strange, although one can think that changing core.autocrlf might imply that the files in the workspace might have no longer the same contents that they had should they have benn checked out with the new core.autocrlf. Be as it is, at least this unexpected effect of changing core.autocrlf should be documented.
-Angelo Borsotti