git marking unchanged files as changed

Question

Here is the basic problem: git seems to mark all my files as changed, even though there are no changes. Even the diff does not show any difference, still it wants me to staged / commit all files anew. How can I convince git that there are no changes in a way that still tracks changes made from that point on?

I have a git repository that I edit on two separate computers (both are Macs). I use to transfer them using an encrypted filesystem image on a USB stick and copied using rsync. When I transfer the files to my laptop, all files are marked as changed. If I just ignore git and work on the files, rsync'ing it back, the other machine will correctly recognize only the changed files once more. So it sorta works, but it's really inconvenient for working on my laptop when I can't commit my changes until I get back to the other machine as by then I'll have to commit several changes in one single checkin.

Answer 1

Turns out it was'nt the line endings after all. I doubted that solution as I assumed that git would then have shown every line as changed - which it did not. But today I stumbled over a small little entry that was log when I checked the files back in at my work machine - the file access rights had been changed from 644 to 755 (or vice versa) while being transferred between the machines.

The solution is right here on stackoverflow in this question: How do I make git ignore mode changes (chmod)?

Answer 2

I would check whether the line endings are being changed in the transfer. While this can be a real pain to deal with, you can help control for it using the core.autocrlf option, as described in this question.

I would also definitely check out GitHub's help section on line endings, as it has some good advice on dealing with this type of problem (assuming that it actually is your problem).