Given what you say about your .ogg file, it is probable that git's heuristic thinks they are [in some cases] binary (perhaps they are unicode files which will contain Null bytes) and won't therefore convert the line endings.
The Git for Windows and Linux version of Git have slightly different default settings, so do check what they are. The line [EOL] and file [EOF] ending converstion discussions are spread over two or three man pages, and do take a bit of time to appreciate all the different normalisation issues. You can also try expanding the repo's blobs (using plumbing commands), and comparing those to the work tree files in the two OS's to which bytes are being changed, and in which direction. Philip ----- Original Message ----- From: Matthew Johnson To: [email protected] Sent: Thursday, January 31, 2013 1:22 AM Subject: [git-users] Re: Why Same Files show up with different Statuses in Git? Good guess, I had not been thinking about the different EOLs, but all the files that show up as modified only under Fedora are .ogg files: no EOLs at all. Even weirder, the textual files, whether HTML or JavaScript, do not have this problem. So it is hard to see how EOL inconcistency could explain why sound files are showing up as modified. On Wednesday, January 30, 2013 11:30:28 AM UTC-8, Alex Lewis wrote: I think this question on stackoverflow might help... - http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Basically the problems stems to you using the same physical repo with two different types of Git client, one built to use Windows EOL and the other using Linux EOL. When you mix the two, I.e. work with a file in Linux when it was created whilst on Windows I think you'll run into problems. I think if you set up the Windows client correctly (or specifically use the .gitattributes file for the repository) I think you'll be ok. HTH On Wednesday, 30 January 2013 02:40:47 UTC, Matthew Johnson wrote: I hate to cross post, but I can no longer see my message to the same effect at the Git mailing list, where I got no reply, so here we go: First, some background. I have one hard disk separated into two partitions: one for the version of Windows 7 that shipped on this rather new Thinkpad (Windows 7 Professional SP1), the other for Fedora 17 (which I installed and keep up-to-date). Of course, it is rather easy to access the Windows partition from the F17 partition, which I have been doing with no noticeable problems: the File Explorer equivalent, Dolphin (the KDE equivalent) will automount the Windows partition as a filesystem under /media, I only have to enter the password for 'su'. I don't think it makes a difference, but for completeness I provide the options with which I find it mounted: /dev/sda2 on /media/Windows7_OS type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096). Anyway, the problem is this: the very same files, e.g. /media/Windows7_OS/cygwin/home/Matthew Johnson/MrEd/mr.ed/lesson1/images/home-icon.jpg show up as 'modified' when I type "git status" (in the mr.ed/ dir) using the F17 git client, but do not show up at all when I type "git status" under the Cygwin client. This problem is not on all files, only a few, predominantly in two directories. Under Windows (cygwin) "git status" shows nothing to commit, only untracked files, which is what I expect; only under F17 do I get several modified files -- and these have old dates (e.g. Nov 27). Yes, that is another important note: I am running Cygwin on the Windows partition. The versions of things under the F17 partition are: Linux 3.7.3-101.fc17.x86_64 x86_64 System: Fedora release 17 (Beefy Miracle) KDE: 4.9.5 git --version git version 1.7.11.7 Under Cygwin, the git version is 1.7.9. Finally, I did check the git configuration to make sure the same user.name and user.email are set in both. And in both cases, I made mr.ed the current directory before executing "git status". Shouldn't that be enough? Is there anything else that must match in the git config? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6068 - Release Date: 01/30/13 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
