File modified after git clone

Question

After clone a github repository in my PC, a file is showing like a modified file. But the last modification in this file was done 8 months ago. How is possible? I tried execute "git checkout -- ." but the file continues like a modified file.

The .gitattribute file:
*.java text
*.scala text
*.xml text
*.properties text
*.properties.default text
*.sh text
*.pig text
*.py text
*.md text

The problematic file is a java source. And I'm using Ubuntu 12.10

Anybody have a tip/solution for the problem?

I've seen something similar and my best guess is there is some hook is modifying files on clone. — Michael, Feb 26 '13 at 21:58
Can you do 'git diff' and see if there is anything meaningful that has been changed? — Bhaskar, Feb 26 '13 at 22:42
When I execute "git diff" is like all lines of file have been deleted and included again — vanz, Feb 26 '13 at 23:29
What is `core.autocrlf` set to? What kind of filesystem are you on? NTFS? FAT32? SMB? — Edward Thomson, Feb 27 '13 at 01:46
@EdwardThomson the core.autocrlf is set to input and the core.text is set to auto. My filesystem é ext4. — vanz, Feb 27 '13 at 02:11
@vanz: Thanks, sorry, one more clarification. When you say that it appears modified, you mean that `git status` shows it as such, correct? If not, how are you determining that it appears modified? — Edward Thomson, Feb 27 '13 at 02:17
@EdwardThomson Yes, exactly. When I execute a git status the file is shown like a file with modifications. The changes is not staged for commit. — vanz, Feb 27 '13 at 02:20
Are there other files in the repository that don't behave like this? — gcbenison, Mar 10 '13 at 15:41
Possibly related: http://stackoverflow.com/questions/15345846/sometimes-git-tells-me-every-file-is-new-and-unstaged — gcbenison, Mar 11 '13 at 21:27

score 0 · Accepted Answer · answered Feb 27 '13 at 04:26

0

just set a git core.filemode false will solve your problem.

Br, Tim

answered Feb 27 '13 at 04:26

Tim

2,006
2
18
25

Even after setting `core.filemode false` and `core.autocrlf false` I still having this same problem. Any tips? – wviana Sep 30 '15 at 15:03

score -1 · Answer 2 · answered Feb 27 '13 at 01:44

-1

Whenever git checks out some file (like after a clone) it sets the modified time to the current time.

Consider the following scenario: You have branches, creatively called One and Two. You check out One, and run make. Then you check out Two, and run make again. There is a certain file, called just that, that was last modified 1 and 2 months ago in the respective branch. If git checked out file with it's original modified time, each time you switch branches file will have been modified a long time ago as far as make sees. Not A Good Thing (TM).

answered Feb 27 '13 at 01:44

vonbrand

11,412
8
32
52

That's only true if the file has changed. If I am to switch branches and an item has the same contents in both branches (eg, if the destination tree item matches my current index item) then the `mtime` is not updated. Otherwise, when I switch branches all my files would have their `mtime` updated and `make` would rebuild everything. And that, too, would not be a "Good Thing". – Edward Thomson Feb 27 '13 at 02:16
1

Regardless, this doesn't answer why `git` would see the files as modified after it checked them out itself. – Edward Thomson Feb 27 '13 at 02:21
@EdwardThomson, I _explicitly_ gave the example with two different versions. After a `clone` the files _are_ checked out for the first time (there is no "unchanged version from the other branch"). `git` is smart, but it can't read minds to find out what the "correct" time would be, it just takes the safest option. – vonbrand Feb 27 '13 at 02:27
Your example includes this case, but your first paragraph talks about "whenever `git` checks out some file". This presumably includes the `checkout` command, and it suggests that `mtime` is always set to current time. – Edward Thomson Feb 27 '13 at 02:32
And if the file hasn't changed, it isn't checked out ;-) – vonbrand Feb 27 '13 at 02:38
Yes, well, I'm not trying to be argumentative, I'm just trying to tell you that I found your answer unclear. – Edward Thomson Feb 27 '13 at 06:52
@EdwardThomson, if you think it can be said better, go ahead and edit my answer. – vonbrand Feb 27 '13 at 19:38

File modified after git clone

2 Answers2

Linked